HDTenEightyP/NetNews huggingface dataset:
From: tremblay@flayout.Eng.Sun.COM (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: Interleaving the caches like memory? Newsgroups: comp.arch
Date: 5 Nov 1992 17:30:14 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: flayout
Keywords: memory cache, associative memory, searching, sorting

In article <1992Nov3.131105.21763@klaava.Helsinki.FI> veijalai@klaava.Helsinki.FI (Tony Veijalainen) writes:
>Memory on high speed microcomputers is divided in multiple regions
>according to <address> mod <interleave factor>.  Is it sensible to have
>them cached with separate cache controller and mayby raise the frequency
>of accessing sequential locations over the physical limits of sequential
>access of one cache chip.  Second possibility would be having cache to
>spy branch instructions like modern CPU:s and have parallel pre-cached
>instruction pathes instead of instruction pipelines like CPU.  This
>sounds sensible to me.

One can certainly have multiple banks for the on-chip caches as well as
the off-chip caches. For instance, a superscalar processor can support 2 loads
per cycle by implementing the data cache through two or more banks. This is cheaper
than dual-porting the whole cache. For general purpose code, collisions do
occur between the load addresses but for a reasonable number of banks the
percentage is low which justifies the use of banks.

One issue that comes across for deeply pipelined machines is that for addresses
computed as a sum of two values, it is not known "up-front" (before register file access)
if the addresses will collide or not. Generating stalls a few cycles deep into
the pipeline is not desirable since it increases the CPI (versus scheduling up-front).
If the caches are interleaved using some low order bits then a short addition
done after the register file access is enough.  Notice that even if the cache indexes
required translated bits (e.g. when page size * associativity < cache size) this can
still work since the low order bits are left alone.

- Marc Tremblay.
Sun Microsystems.
Newsgroups: comp.arch
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: IEEE used for Dollars and Cents
Organization: Keith's Computer, Hope Mills, NC
Date: Thu, 05 Nov 92 13:23:45 GMT

In article <Bx5xnJ.BC8.1@cs.cmu.edu> nickh@CS.CMU.EDU (Nick Haines) writes:
>In article <1992Nov01.165646.10222@ksmith.uucp> keith@ksmith.uucp (Keith Smith) writes:
>
>   In article <BwyBs0.M88.1@cs.cmu.edu> nickh@CS.CMU.EDU (Nick Haines) writes:
>   >All business software everywhere uses integer arithmetic.

>   What do you mean "integer".  BASIS BBx (business basic extended) uses 14
>   decimal place BCD math.  They also support integers.  I don't consider
>   BCD math "integer".  There are a TON of Business apps written in
>   Business BASIC, commercial and otherwise.
>

[ COBAL STRING, ETC ]

>I meant `fixed point decimal,' I guess. I meant the sort of math that
>COBOL and Business BASIC use. I spent over a year hacking that sort of
>code (most of it DG Business BASIC versions 5-8, which actually does
>use integers everywhere), and trying to imagine what it would be like
>using FP gives me heeby-jeebies.

BASIS uses a FLOATING POINT BCD.  Fixed point to me means number have n
places to the right of the decimal.  BASIS BBx stores numbers with 14
places of PRECISION using 8 bytes with a 7 byte BCD mantissa, and the
other 8 bits for sign & exponent (+-2^6 exponent I beleive).

I'm not sure about the RPG's, but I think it uses arbitrary precision
string math.  In the COBOLS I beleive most were fixed point.

>It's all a trade-off. If you have to use FP, you have to do rounding
>on _every_ operation. If you have to use (large) integers, you only

If you do it in FP you will forget to do *SOMETHING* on some operation
that will *LOOK* right when scanning the code that you will spend many,
many hours looking for to correct, which will in turn show yet another
problem ....
-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
Newsgroups: comp.arch
Subject: Re: Exponential Random Number Generator
Date: 5 Nov 92 09:46:54 GMT
Organization: Computer Science Department, Oregon State University
NNTP-Posting-Host: jade.cs.orst.edu

In article <1dam8vINNl5@flop.ENGR.ORST.EDU>
crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
>After spending substantial time with Herman Rubin's random number
>generator routines, ...  I wrote the following program to generate
>random numbers ...

Before I forget, Cliff Click has tried some alternative routines to the
ones I provide in the program.  Since my code is new, we haven't done
a comparison yet.

-- 
  Lawrence Crowl		503-737-2554	Computer Science Department
			   crowl@cs.orst.edu	Oregon State University
	      ...!hplabs!hp-pcd!orstcs!crowl	Corvallis, Oregon,  97331-3202
Newsgroups: comp.arch,comp.lang.forth
From: rminnich@super.org (Ronald G Minnich)
Subject: Re: What's RIGHT with stack machines (Was Re: What's wrong...)
Keywords: stack computers, embedded control
Organization: Supercomputing Research Center (Bowie, MD)
Date: Wed, 11 Nov 1992 13:45:56 GMT

In article <Bx5AIr.EAy.2@cs.cmu.edu> koopman+@cs.cmu.edu (Philip Koopman) writes:
>PIPELINING
I am not replicating your comments, but will only say that some 
people I used to know at Burrough-- oops, 
Unisys would be surprised by this one. Find out what you can about the 
A17, and you will see a machine that does a fair amount of work to convert
the old stack machine instruction set to Something Else on the fly, and then 
executes that. Or look at earlier machines, such as the A15. 
There is a pipeline or two in there :-)
>STACK SIZE & INTERRUPTS
>A neat thing about stack CPUs is that context switching for
>interrupts takes essentially zero time -- no registers need
>to be saved; you just put the ISR values onto the top
>of the stack and clean them off when you're done (presumes
Only if you don't care about protection, right? otherwise you have to 
switch stacks, and switching stacks implies flushing on-processor 
state related to the current stack. Of course if you only have one 
process ...
>COMPILERS
>Stack compilers aren't currently very efficient -- but
>that's because no-one has really tried all that hard.
Screams from Paoli, Pa. and other places were probably heard on 
this one. A lot of good work was done by one company over a period 
of decades. 

ron

-- 
Never assume a conspiracy when you can assume     | rminnich@super.org
incompetence.                                     | (301)-805-7451 or 7312
Most abused words: open, scaleable, [more later]  |
Xref: sparky comp.arch:10525 comp.unix.bsd:8607 comp.os.linux:16036
From: hood@kpc.com (Robert Hood)
Newsgroups: comp.arch
Subject: Re: integer/BCD/... dollars (was IEEE used for Dollars and Cents)
Date: 9 Nov 92 16:22:43 GMT
Organization: Kubota Pacific Computer, Santa Clara Ca.

In article <27311@dog.ee.lbl.gov>, torek@horse.ee.lbl.gov (Chris Torek) writes:
|> (Last word on this non-computer-architecture stuff :-) )
|> 
|> I wrote:
|> >> Signed integers are not an absolute must, but precision greater than
|> >> one penny is; most businesses seem to keep records to five digits or so.
|> 
|> In article <2664312@zl2tnm.gen.nz> don@zl2tnm.gen.nz (Don Stokes) writes:
|> >Figures are only _published_ to five digits or so.  Bookkeeping must be
|> >to the last cent,
|> 
|> Sorry, I meant `five digits past the decimal point', the decimal point
|> being dollars.  These are apparently called `mills', i.e., thousanths
|> of a cent ($0 + 0 cents + 0.001 cents = 1/1000 cents = 0.00001
|> dollars).
|> In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
|> Berkeley, CA		Domain:	torek@ee.lbl.gov


From the American Heritage dictionary:

	mill: A monetary unit equal to 1/1000 of the dollar of the United
	      States.

Bob
From: tbrann@black.ox.ac.uk (Tony Brannigan)
Newsgroups: comp.arch
Subject: Re: News Release - Pentium - "INTEL UNVEILS NAME FOR ITS FIFTH GENERATION COMPATIBLE MICROPROCESSOR"
Date: 7 Nov 92 17:27:05 GMT
Organization: Oxford University Engineering Dept.
Originator: tbrann@black

All this arguing about the name is fine, but when are we going to see
it, whatever it is called?  I vaguely remember the original article,
and the Intel dude iced over this question if I remember rightly...

I think the release date will be more important than the name.
(even if the name does sound like a component of a nuclear reactor ;)

Tony's $0.02 worth
-- 
"And soon all of us will sleep under the earth, | tbrann@oxford.ac.uk
  we who never let each other sleep above it."  | u90afb@ecs.oxford.ac.uk
   Marina Tsvetayeva 1915                       | tonyb@nyx.cs.du.edu
Newsgroups: comp.arch,comp.unix.bsd,comp.os.linux
From: danh@quantum.on.ca (Dan Hildebrand)
Subject: Re: IDE faster than Mips SCSI disk
Date: Fri, 06 Nov 92 15:08:46 GMT
Organization: Quantum Software Systems

In article <1992Nov6.033942.21194@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
>These figures are not meant to be a thorough study. More of a provocation
>for more soul searching. The widespread belief that SCSI-2 is "defininely
>faster than IDE" is questionable, in fact under some circumstances, entirely
>false.

One significant point you're missing is that IDE drives use the processor 
to move the data in and out of the controller card, while SCSI on a PC with 
an Adaptec 1542 or 1742 controller card is a bus master. This fact lets the 
host processor continue computing while the SCSI card does the data 
transfer. If the processor is consuming or producing data at near the rate 
the SCSI card moves it, the resulting pipelining provides in significantly 
better performance. For a DOS system, which just waits while the disk I/O 
is in progress, it doesn't make a lot of difference, but with a 
multitasking OS, or a filesystem which is doing pre-reads and post-writes, 
the overlap of I/O with computation is a worthwhile goal.

>The mips machine under test runs on ultrix. Although it has up to 10Gbyte 
>of hard-disk, it is not so heavily loaded. We only use it for email and
>news feed. Fragmentation can be severe because I cannot even have 32 
>megabyte free space in /usr/tmp , only 30 Mbytes.
>
>	IOZONE: Performance Test of Sequential File I/O  --  V1.14b (1/31/92)
>	Operating System: ULTRIX
>
>IOZONE performance measurements:
>	345684 bytes/second for writing the file
>	641985 bytes/second for reading the file
>
>486/33 Maxtor 7120 200Mbyte
>
>IOZONE performance measurements:
>	367586 bytes/second for writing the file
>	499942 bytes/second for reading the file

Running IOZONE with QNX on an ISA bus, 33 MHz 486 with only the 8K 
processor cache ( no motherboard processor cache ), I sustain about 1.6 
Mbytes / second read and about 800 Kbytes / second write ( 32 Mbyte files 
). This is essentially the platter speed of the drive. Of all the IDE 
drives I've tried so far, the best performance I've seen was about half 
that on both read and write, respectively. Local bus will help to speed up 
IDE drives, but local bus will also speed up SCSI. Bus mastering is still 
the important difference. I suspect a bus mastering IDE controller card 
could compete with an Adaptec SCSI controller and disk drive.


-- 
Dan Hildebrand                     email: danh@qnx.com
Quantum Software Systems, Ltd.     QUICS: danh  (613) 591-0934 (data)
(613) 591-0931 x204 (voice)        mail:  175 Terrence Matthews          
(613) 591-3579      (fax)                 Kanata, Ontario, Canada K2M 1W8
Newsgroups: comp.arch,comp.lang.misc
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: A challenge to the anti-goto
Organization: Los Alamos National Laboratory
Date: Thu, 5 Nov 1992 18:15:11 GMT

In article <1992Nov5.111943.21554@harlqn.co.uk>, daveb@harlqn.co.uk (Dave Berry) writes:
|> It's easy to get rid of these gotos.  Every goto can be replaced by a
|> tail-recursive function call.  This can be compiled into the same machine
|> code.  Here is Herman's example, gratuitously rewritten in ML.

I posted this a couple of weeks ago, but my newshost daemon blocked
my outgoing mail at that time.

"Structured Programming With GOYTO Statements", D.E. Knuth, Current
Trends in Programming Methodology, R.T. Yeh Ed., Prentice-Hall, Inc.,
1977:

   [...] Rule number one for simplifying procedure calls is:

      If the last action of procedure p before it returns is
      to call procedure q, simply GOTO the beginning of procedure 
      q instead.

   (We must forget for the time being that we don't like GOTO
   statements.)  It is easy to confirm the validity of this rule,
   [...]
   Incidentally, the converse of the above rule is also true (see
   [Knuth and Floyd, "Notes on Avoiding GOTO Statements", Computer
   Science Technical Report CS148, Stanford University (1979)]):
   GOTO statements can always be eliminated by declaring suitable
   procedures, each of which calls another as its last action.
   This shows that procedure calls include GOTO statements as
   a special case; it cannot be argued that procedures are
   conceptually simpler than GOTO's, although some people have
   made such a claim.

In short, a procedure call is *at least* as messy, non-local, and
spaghetti prone as GOTOs.  In common practice, GOTOs are presently
*easier* for the compiler to analyze and optimize than interprocedural
calls are.  To be sure, the code which is done as procedure calls
*can* be compiled to the same code by a *very* clever compiler
(and assuming that the language doesn't require that separate
compilation work).  Last, but not least, is the fact that *sometimes*
a GOTO is actually easier to read and maintain (though I'm still
not sure this is the case with Herman Rubin's program).

-- 
J. Giles
Newsgroups: comp.arch
From: des@inmos.co.uk (David Shepherd)
Subject: Re: Mixing Greek/Latin in product naming (was: Re: <None>)
X-Newsreader: Tin 1.1 PL5
Date: Thu, 12 Nov 92 09:40:31 GMT

peter da silva (peter@ferranti.com) wrote:
: According to legend, Ford did originally want to call his version of the
: car the Ipsimobile and was dissuaded by an investor...

.. typical ... financiers telling  an engineer what to do :-)

--
--------------------------------------------------------------------------
david shepherd: des@inmos.co.uk or des@inmos.com    tel: 0454-616616 x 625
                inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq
                1992: celebrate the quincentenary of columbus getting lost
From: john@gu.uwa.edu.au (John West)
Newsgroups: comp.arch
Subject: Re: RTX and SC32
Date: 6 Nov 1992 05:29:58 GMT
Organization: The University of Western Australia
NNTP-Posting-Host: mackerel.gu.uwa.edu.au

lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:

>It would be interesting to know exactly what instructions cause this 
>(alleged?) speedup.  Could one or two instructions be added to a standard 
>RISC processor (SPARC/MIPS/m88k/RIOS/HP-PA) to support the same operations
>and provide the same speedup?

I don't think it is any actual instructions that cause the speedup, but the
whole architecture of the processor. Its just designed to do stack intensive
things simply and quickly. You could try adding on-chip stacks with fast access
to a standard RISC chip, but you'd end up with something looking more and more
like a Forth chip. It isn't instructions. Its a totally different way of
looking at things.

>I suspect that standard RISCs already provide what is needed to run Forth
>efficiently, they just are not handled in one cycle on load/store machines.  

No. Load/store architectures are designed to use registers as much as possible,
without going to memory unless it is really needed. Unfortunately, the stack(s)
always go in memory. Your single Forth instruction to add two numbers can be
executed in a single cycle, but on the load/store processor, you've got two
memory reads, the operation itself, and then a memory write - all memory
accesses changing the stack pointer. This sort of destroys any hope of
going superscalar with any sanity.

>So, the question remains:  are there any Forth operations which are not
>efficiently supported on the current crop of RISCs, and are on the 
>named Forth machines?  If so, what operations are they, and why?

The answer remains: stacks. Load/store is nowhere near as good at stack
handling as a dedicated stack architecture, simply because it was never
designed to be.

RISC processors were designed to run the same sort of languages as CISCs.
They run C very well. Forth and its friends are very very different languages,
and you need a processor dedicated to running that sort of language to do it
well. I don't think they can really be compared - not at a low level, anyway.
They're just too different. The only valid comparison is how well it does the
job.

John West
--
For the humour impaired: Insert a :-) after every third word
Organization: Robotics Institute, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.arch
Date: Wed, 11 Nov 1992 12:46:56 -0500 
From: "Jon C. R. Bennett" <jb7m+@andrew.cmu.edu>
Subject: Re: MINIMUM instruction set
	<1992Nov11.144304.10494@news.uiowa.edu>

jones@pyrite.cs.uiowa.edu (Douglas W.Jones,201H MLH,3193350740,31933828 writes:
> From article <1992Nov10.235849.19192@fcom.cc.utah.edu>, by val@news.ccutah.edu\
>  (Val Kartchner):
> > I've heard that it is possible to implement all programming languages with
> > seven instructions.
> 
> What is an instruction?  Ignoring I/O, the following CISC instruction does
> the job:
> 
>         DB <op1> <op2> <op3>
>                 Decrement <op1> by <op2> and branch to <op3> if the result
>                 is less than zero.  All operand fields address memory.

i think that perhaps a better question, and one which i think you almost
answered is, "How many operations are needed...."
the instructions that you present do the following

load
store
subtract
compare
branch

the only things i can think of that are missing are

shift
bit op (and,or,xor)


jon
From: andrew@bic.East.Sun.COM (Andrew Harrison - Sun UK - Cambridge Consultant)
Newsgroups: comp.arch
Subject: Re: IDE faster than Mips SCSI disk
Date: 9 Nov 1992 16:15:53 GMT
Organization: sundc.East.Sun.COM
Distribution: world
Reply-To: andrew@bic.East.Sun.COM (Andrew Harrison - Sun UK - Cambridge Consultant)
NNTP-Posting-Host: bic.uk.sun.com




The block size used does make a big differance but so does having a
decent SCSI platter
to deal with.

If the figures I have for SCSI are anything to go by, 600 Kb/s read and
write for IDE
mean that these drives and the I/O interface on the PC have a way to go.


I tested a 1.3 GB SCSI Seagate Elite and a 424 MB SCSI drive, don't know
its name
on a SPARCstation 2.
Both Drives are standard SUN drives running on a 5 MB/s SCSI. They are
not the fastest drives 
SUN sells. There are a 1 GB and 2.1 GB drive both of which operate on a
10 MB/s SCSI bus and
both of which have lower average access rates and higher burst transfer
rates than the 
1.3 GB drive on the SPARCstation 2.


1.3 GB 
	iozone 100

	Default uses 512 byte blocks.


Writing the 100 Megabyte file, 'iozone.tmp' ...64.637813 seconds
Reading the file...54.335514 seconds

IOZONE performance measurements:
	1622438 bytes/second for writing file
	1930160 bytes/second for reading file

If we up the block size to 8192
	iozone 100 8192

Writing the 100 Megabyte file 'iozone.tmp' ...43.474970 seconds
Reading the file...27.846924

IOZONE performance measurements:
	2411907 bytes/second for writing the file
	3765500 bytes/second for reading the file

These results come from the middle of the 1.3 GB disk. As the disk is
ZBR its transfer 
rate is faster on the outer traks than the inner tracks , so this is an
average result.

424 MB disk.

This is the standard internal SCSI drive in SS2's and SS10's.

	iozone 32

	Default uses 512 byte blocks

Writing the 32 Megabyte file 'iozone.tmp' ...26.460000 seconds
Reading the file...19.550000 seconds

IOZONE performance measurements:
	1268119 bytes/second for writing the file
	1716339 bytes/second for reading the file

If we up the block size to 8192
	iozone 32 8192

Writing the 32 Megabyte file 'iozone.tmp' ...22.540000 seconds
Reading the file...10.720000 seconds

IOZONE performance measurements:
	1488661 bytes/second for writing the file
	3130077 bytes/second for reading the file

I would expect the 1 GB and 2.1 GB drives to be 20 - 30% faster but I
havn't got any
in my machine to test.

IOZONE uses read and write. This imposes a system call overhead. In
practice more 
efficient I/O can be acheived using mmap() which considerably reduces
the system 
call overhead. 


Andrew Harrison

SUN UK Consultancy 
	

Newsgroups: comp.arch
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: RISC goes CISC?
Reply-To: vhs@rhein-main.de
Date: Fri, 6 Nov 92 09:20:12 GMT

I was wondering lately...
Wasn't one of the principles of RISC the principle of putting as much work
as possible from execution to compile time?
Under this assumption, how does e.g. SuperSPARC fit this principle? As far
as I know the processor does a lot of cross-checking between pipelines,
squashing instructions depending on non-trivial conditions, etc. Is that done
just to maintain compatibility with previous implementations?
Could, theoretically, the most recent compilers take care of this
at compile-time, thus eliminating the need for run time
checking (again theoretically since people want to run their old code).
Wasn't the architectural(?) definition of using exactly one delay slot
extremely short sighted, taking into account the much longer pipelines in
current implementations?
Aren't pipelines necessary so that instructions that take several cycles
(i.e. "complicated" instructions) can be issued one per cycle? Wouldn't
it conform more to the RISC principle to keep instructions so simple
that they only *need* one cycle to execute and concentrate on a *fast*
memory interface instead? Will RISC go the way that CISC went?
Will PCs ever compare favorably to workstations? Will Jane marry Tarzan?
Will this nonsense ever end? Will someone answer?
...

This is not meant to flame SPARC processors. They're just the RISC
processor I know best (which does not say much, obviously).

--
Volker Herminghaus-Shirai (vhs@rhein-main.de)

I'm a .signature antivirus. Help defend the net against the evil .signature
viruses and copy me into your .signature file.
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: MIPS R4400
Organization: Digital Equipment Corporation
Date:  9 NOV 92 16:04:06    


In article <lftam5INNgoi@exodus.Eng.Sun.COM>, walter@zarquon.Eng.Sun.COM (Walter Bays) writes...
>>In article <JCALLEN.92Nov6135200@marley.think.com> jcallen@marley.think.com (Jerry Callen) writes:
>>[I was surprised to see MIPS use SPEC 89 numbers...]
> 
>I also wonder why you would use the old 89 suite.  Was it that some of
>the new 92 benchmarks are too complicated to simulate, in particular
>026.compress and 072.sc?  (I believe there are ways around the
>difficulties.)  But even if SPECint92 was intractable, can't you at
>least simulate SPECfp92?
> 
Simulation is slow and often difficult when a benchmark does I/O. It is a lot
easier to do 10 benchmarks that have been around for 3 years, than it is to do
20 relatively new ones. With SPEC89 numbers in detail, one can make reasonable
guesses at SPECint92 and SPECfp92.

While more would be better, it is nice to see some numbers with backup data.

Dileep
From: stevel@coos.dartmouth.edu (Steve Ligett)
Newsgroups: comp.arch
Subject: 600 transistor CPU (was: MINIMUM instruction set)
Date: 12 Nov 92 16:45:10 GMT
Organization: Dartmouth College, Hanover, NH

Somewhere I have a copy of an article (or two) titled

"A design for a 16 bit processor using only 600 transistors"

from Microelectronics Journal, Vol 15, Nr 3,
copyright 1984 Benn Electronics Publications Ltd, London

The machine has 4 instructions: three subtracts, and one bit clear.

I'll try to find and reread the articles if it would be of interest.
-- 
steve.ligett@dartmouth.edu
Sign in our Machine Room:  Before Leaving Please Lock Door Behind You