HDTenEightyP/NetNews huggingface dataset:
From: mash@mash.wpd.sgi.com (John R. Mashey)
Newsgroups: comp.arch
Subject: Re: One Instruction Computers
Date: 2 Oct 92 21:48:30 GMT
Organization: Silicon Graphics, Inc.

In article <1992Oct2.192543.12309@dartvax.dartmouth.edu>,
mac@coos.dartmouth.edu (Milton A. Colvin) writes:

|> The first NED processors were based on the Able minicomputer, notable
|> for it single instruction - MOVE. MOVE encodes an 8-bit source and an
|> 8-bit destination.
|> 
|> As far as I know, this was the only commercial one-instruction
|> machine.  For its time it was quite fast. A number survive in
|> Synclaviers and as network routers at Dartmouth.

From the description, I don't think that most people would call that
a 1-instruction computer, for the same reason that opcode-counting is
generally difficult to do in a sensible way.  AS discussed before:
Machine A:
	Load 32 bits
	Load 16 bits signed-extended and load-16-bits-zero-extended
	Load 8 bits signed-extended and load-16-bits-zero-extended
	I.e., 5 opcodes
Machine B:
	Load ... plus a 3-bit qualifier field that says 32, 16s....
	I.e., 1 opcode
Any arguments based on Machine B being simpler than A, based on having 1
opcode rather than 5, are just plain silliness.  It's simply an encoding
issue.

	  
-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090
USPS:   Silicon Graphics 7U-005, 2011 N. Shoreline Blvd, Mountain View, CA
94043
Newsgroups: comp.arch
From: rf@cl.cam.ac.uk (Robin Fairbairns)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Reply-To: rf@cl.cam.ac.uk (Robin Fairbairns)
Organization: U of Cambridge, England
Date: Wed, 30 Sep 1992 12:03:19 GMT


In article <1992Sep29.185157.14497@odin.corp.sgi.com>,
mash@mash.wpd.sgi.com (John R. Mashey) writes:
|> In article <1992Sep29.095212.24225@odin.diku.dk>, torbenm@diku.dk (Torben
|> AEgidius Mogensen) writes:
|> 
|> |> >IBM found out the hard way that if you don't _enforce_ "reserved and
|> |> must be
|> |> >zero", you lose the ability to grow later... because the 360
|> |> architecture
|> |> >allowed the high-order byte of address fullwords in memory and GP
|> |> registers 
|> |> A similar problem occurs in the ARM processors: in the first ARM
|> 
|> EVERY MISTAKE IN COMPUTER DESIGN HAPPENS AT LEAST 3 TIMES:
|> 
|> 1) First, it happens in mainframes.
|> 2) Then, it happens in minicomputers.
|> 3) Then, it happens  (at least once) in microprocessors.
|> 
|> This is a classic one, of course, I although I can't finger the
|> minicompute one offhand.
|> 
|> 1) S/360 24-bit addressing.*
|> 2) minicomputer?

The CTL Modular One*.  16-bit machine - 13-bit PC, 3 status bits
stored when you took an interrupt, etc.  In fact, this limit of 8K
(words) on the program segment didn't take particularly long to bite
them pretty hard - everything was fine until they got the first
compilers going for the machine.  (It would have failed before then,
but they employed idiots to design their assembly language so that it
took a long time to write anything significant ;-)

|> 3a) MC68000 24-bit addressing (remember the Mac apps that failed when
|> 	the Mac-II came out, because the 68020 did *not* ignore the
|> 	high-order bits?
|> 3b) ARM....
|> [...]

* British computer made in an inflatable bubble-factory in Hemel
Hempstead.  Predated the PDP-ll by a bit: when the PDP-11 arrived, CTL
acted all propietary about the number 16 at trade shows....
--
Robin (dump Brian Kay) Fairbairns                    rf@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge  CB2 3QG, UK
Newsgroups: comp.arch
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: need ftp site for Specmark program
Organization: Metaflow Technologies Inc.
Date: Wed, 30 Sep 1992 18:44:39 GMT

In article <BvECrx.L63@inews.Intel.COM>, jwreilly@mipos2.intel.com (Jeffrey Reilly) writes:
|> In article <2AC8F951.9029@news.service.uci.edu> jtien@venice.eng.uci.edu (Joe Tien) writes:
|> >
|> >Could someone tell me the ftp site for the Specmark benchmark program (in C).
|> 
|> The SPEC benchmarks suites are licensed software products. You can
|> obtain information about obtaining them from...

True, but some of the SPEC benchmarks stem from freely available
code.  I would say that if you are simply interested in researching
cache behaviors, you might want to get your hands on similar programs.
For example, one of the integer SPECmarks is gcc, the gnu C compiler.
This ought to be available pretty easily.  I'm not sure about others --
anybody have suggestions?
-- 

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.arch
Subject: Re: Fully associative cache
Date: 3 Oct 92 16:27:44 GMT
Organization: Department of Computer Science, U of Copenhagen

cprice@mips.com (Charlie Price) writes:
>thorinn@diku.dk (Lars Henrik Mathiesen) writes:
>>cprice@mips.com (Charlie Price) writes:
>>Why is the buffer ``a couple'' deep? One should suffice.

>If you have, for example, back-to-back store instructions the first
>store will be written from a store buffer entry in the same cycle
>that you are stashing the data from the second store into the store
>buffer.

But the buffer only needs to hold one entry ``between'' cycles, right?
I think that I was counting the entries at some logical block diagram
level, while you were thinking of the number of latches needed to
implement the thing.

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
Newsgroups: comp.arch
From: jcarroll@ferris.cray.com (Jeff Carroll)
Subject: Re: ALPHA, a year and counting
Originator: jcarroll@ferris
Organization: Cray Research, Inc.
Date: 2 Oct 92 22:34:32 CDT


In article <1992Sep28.011619.29047@adobe.com>, zstern@adobe.com (Zalman Stern) writes:
> In article <1992Sep25.173220.26288@crl.dec.com> jg@crl.dec.com (Jim Gettys)  
> writes:
> > As Daryl Morse notes, Alpha is from scratch; software is the issue,
> > rather than hardware.  So it isn't the situation of the N'th generation
> > chip of the same architecture.
> Some would claim that it wasvery dubious of DEC to introduce a completely  
> new, incompatible architecture with no software support and a year of lead  
> time into this computer market.

Others might observe that we are now well into the second if not the third
year since the announcement of the Inmos T9000, which is not yet into beta.

Jeff Carroll
carroll@herndon.cray.com
Newsgroups: comp.arch
From: bmtong@cucs11.cs.cuhk.hk (Tong Bo-Ming)
Subject: Re: DRAMs, etc.
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Date: Fri, 2 Oct 1992 02:44:58 GMT

dschleef@sage.cc.purdue.edu (John Paul George Ringo, III) writes:

>I am not extremely familiar with ICs, and especially DRAMs, but this
>has been bothering me for several years:

>Even though a dram may have a time such as 70ns attached to it, does
>this mean that the chip can only give one peice of information every 70ns?
>In other words, is it possible to pipeline a DRAM, say, sending it an 
>address every 30 ns and picking up the corresponding data 70 ns after
>the address was sent?

>thanks.

>dave.
>(Dave Schleef)

	Of course not !!!  Worst still, 70ns is only the ACCESS TIME, which
means that after you have supplied the address to the DRAM, the data will
come out after 70ns.  However, this does NOT mean that you can read another
data immediately.  You must allow the DRAM to recover, and the total time
is called the CYCLE TIME of that DRAM, which is usually MORE than 70ns !!!
Forget about all those pipelining...

	To get around this problem, try INTERLEAVING.  Say your bus width
is 32 bits.  Get a memory width of 64 bits.  Read all 64 bits every time.
That is, you read TWO consecutive words at a time.  If you are lucky, you
may be able to use it in the next cycle, if in the next cycle the next
word is read indeed.  Of course this will not give a 2x improvement, but
it's very suitable for some particular applications like video RAMs.

	But why not use a cache ?  It has been proven to be the most effective
way to get a low cost/high performance system !

	Hope this will answer your question.

							Tong Bo-Ming
Newsgroups: comp.arch
From: zstern@adobe.com (Zalman Stern)
Subject: Re: ALPHA, a year and counting
Organization: Adobe Systems Incorporated
Date: Mon, 28 Sep 1992 01:16:19 GMT

In article <1992Sep25.173220.26288@crl.dec.com> jg@crl.dec.com (Jim Gettys)  
writes:
> As Daryl Morse notes, Alpha is from scratch; software is the issue,
> rather than hardware.  So it isn't the situation of the N'th generation
> chip of the same architecture.
Some would claim that it wasvery dubious of DEC to introduce a completely  
new, incompatible architecture with no software support and a year of lead  
time into this computer market. Especially when a MIPS-III+VAX FP+something  
PAL like architecture would have been enormously successful and run lots of  
existing software. (And probably caused MIPS just as much pain :-)) Even  
without that, I expect DEC could have shipped Alpha running a Unix with MIPS  
emulation sooner.
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson
Newsgroups: comp.arch
From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: College of Marine Studies, U. Del.
Date: Wed, 30 Sep 1992 11:12:54 GMT

In article <8840078@hpfcso.FC.HP.COM> wlw@hpfcso.FC.HP.COM (Will Walker) writes:
>In comp.arch, desj@ccr-p.ida.org (David desJardins) writes:
>
>> [....] Why shouldn't I be able to use [FP registers] at least as fast
>> temporary storage, for register spilling and the like?
>
>This is a very reasonable question.  I think I may be able to at least
>partially answer it. 
>		[ stuff deleted ]
>For example without a transfer instruction you might do a store and a
>load from cache to do the transfer.  Suppose this takes 3 cycles.  

This is a "best-case" number.  It is easy to imagine circumstances in
which the cache is full so that the store requires saving a modified
cache line and then loading the cache line containing the address that 
you decided to store to.  This can take 30+ cycles on current hardware.
-- 
--
John D. McCalpin                        mccalpin@perelandra.cms.udel.edu
Assistant Professor                     mccalpin@brahms.udel.edu
College of Marine Studies, U. Del.      John.McCalpin@mvs.udel.edu
Newsgroups: comp.arch
From: richk@grebyn.com (Richard Krehbiel)
Subject: Re: One Instruction Computers
Organization: Grebyn Timesharing
Date: Fri, 2 Oct 1992 17:26:31 GMT

In article <MFX.92Oct2130928@lenin.cs.tu-berlin.de> mfx@cs.tu-berlin.de (Markus Freericks) writes:
>There is another way to build a one-instruction computer: Let the only
>instruction be "move" and memory-map the ALUs. This is great if you
>have ALUs that realize multi-cycle operations (e.g. trig FP, table
>lookup). Also, code generation is somewhat easy :-)

This just makes the operation code part of the memory address, it
doesn't reduce the op code count.

The Weitek FPUs for the 386 (3167) and 486 (4167) work this way,
incidentally.  I've read something from them that talks about the
advantage of getting the function code and the data to the FPU in a
single memory cycle by encoding the operation in the lower address
lines.
-- 
Richard Krehbiel                                 richk@grebyn.com
OS/2 2.0 will do for me until AmigaDOS for the 386 comes along...
From: zik@aurora.cc.monash.edu.au (Michael Saleeba [Zik])
Newsgroups: comp.arch
Subject: SUMMARY 2: The definitive architectural reference
Date: 6 Oct 92 12:21:25 GMT
Organization: Monash University, Melb., Australia.

I've had a few responses to my first summary of preferred references
on computer architecture, and a few more suggestions, so here's some
more information for anyone who's in the market for good books!

In my original summary Andrew Wolfe said:

> Kai Hwang is completing a more comprehensive book right now.  Should
> be out in 6 months to a year.

Dana Jacobsen offers further information:

>   Don't know if this is what he's talking about, but I assume it is:
>
> @book{Hwang93,
>   author = {Kai Hwang},
>   title = {Advanced Computer Architecture with Parallel Programming},
>   edition = {Preliminary},
>   publisher = {McGraw-Hill},
>   address = {New York},
>   ISBN = {0-07-031686-4},
>   year = {1993}
> }

And adds:

>   For a book on computer architecture in a more broad sense, I think
> Hennessy and Patterson covers it well, though they have some biases that
> show up.

M. Anton Ertl offers:

* High-Performance Computer Architecture
> Harold S. Stone
> Addison-Wesley, 1987 (2nd Ed 1990)
>
> This was the textbook used here before Patterson&Hennessy

> @Book{kuck78,
>   author = 	"David J. Kuck",
*   title = 	"The Structure of Computers and Computations",
>   publisher = 	"John Wiley \& Sons",
>   year = 	"1978"
> }
>
> Old, but again still hot.

In the first summary I had this:

> * The Sparc Architecture Manual
> >
> > This is a fairly complete reference for the Sparc architecture. This
> > book will give you a good feel for the first commercially successful
> > RISC architecture.

John Mashey took umbrage at the words "first commercially successful":

> Uhh, rewriting of history by SPARC people:
> HP PA, MIPS, and Clipper were shipping 12-18 months
> years earlier. You can argue about whether Clipper was commercially
> successful or not and whether or not it's really a RISC.  However:
> as of YE91, there was (estimated by InfoCorp)
> $10B installed base of systems with MIPS chips in them, not counting
> telephone switches, laser printers, airplanes, etc; MIPS is certainly a
> RISC.
> If HP PA isn't commercially successful [there is certainly somethign like
> $3B/year of business, and they started earlier in serious fashion,
> so they proably ahve a larger installed base $$ than anyone else],
> then I don't know what is.

+-----------------------------------+-----------------------------------+
|          -|-   Zik   -|-          | "The way I see it, ALL students   |
|    zik@bruce.cs.monash.edu.au     |  are expendable."                 |
|          Michael Saleeba          |   - the Vice-Chancellor in        |
|                                   |   "A Very Peculiar Practice"      |
+-----------------------------------+-----------------------------------+
Newsgroups: comp.arch
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: implementing random replacement
Organization: Metaflow Technologies Inc.
Date: Tue, 29 Sep 1992 17:53:25 GMT

In article <FPJ.92Sep28171144@ingrina.inesc.pt>, fpj@ingrina.inesc.pt (Fernando Pereira Jesus) writes:
|> Aditionaly, the shift register stops at empty (flushed) lines, thus
|> ensuring that empty lines are used before lines allready in use.

It seems to me that this would not "ensure" that unused lines are
pressed into service before valid lines are replaced.  There is no
guaranteed time before the random pointer has scanned all values.  The
time to scan all lines is probabilistic.

Using a simple counter has two advantages:  1) You can guarantee that
all lines will be scanned in a finite amount of time (granted, this is
probably just a nit-pick); and 2) You can add a fence register to
protect some lines from replacement.  When the counter matches the
fence register, you reset it.  This is nice if you want to lock certain
lines into the cache.

|> PS: My english is bad, but if I wrote it in Portuguese you probably
|>     wouldn't understand a word :-) !!

Hey, your English is lots better than my Portugese.  You're doing just
fine.
-- 

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
Newsgroups: comp.arch
From: fwebb@star-trek.bbn.com (Fred Webb)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 5 Oct 92 13:32:17 GMT
Organization: Bolt Beranek and Newman, Inc., Cambridge, MA
NNTP-Posting-Host: archive.bbn.com

In article <869@felix.Sublink.Org> eb@felix.Sublink.Org (Enrico Badella) writes:
>... DEC Systems 10 and 20 ...
>I was wondering what was the advantage of having 36 bits instead of 32
>or other 8*n (n>4) architecture.
>Was is just a hardware problem because 48 bits was to difficult to 
>manufacture at that time.
>
>On the DEC Systems 10 and 20 subject, why did they fade away in those
>days when nobody news what Open Systems were?

The DecSystem 20 had 36 bits becuase the DecSystem 10 had 36 bits.  The
DecSystem 10 (originally the PDP-10) had 36 bits becuase the PDP-6 did. The
PDP-6 probably had 36 bits because the PDP-1 had 18 bits (36 = 2*18).

The PDP-6 was designed and built before the days of 8 bit character codes -
at that time most character codes used 6 bits, so there was something to be
said for word widths that were a multiple of 6.  There were machines around
with word widths of 12, 18, 24, 30, 36 and 48 bits.  (Anybody know of a 42 bit
word? I never heard of one.)  Note that 24 and 48 are multiples of 8, but
that's just a coincidence - it was more important that they were multiples of
6.

The first (8-bit) byte-oriented machine was the IBM 360, which was introduced
several years after the PDP-6.  The idea of using 8-bit bytes as the basis of
memory and thus word widths that were a multiple of 8, quickly took over the
industry.  There are probably several reasons for this:

    . 8 is a power of 2, and computer people like powers of 2
    . 6 bits really isn't enough for a decent character code
    . IBM

					-- Fred
Xref: sparky comp.arch:9801 comp.benchmarks:1483
From: jwreilly@mipos2.intel.com (Jeffrey Reilly)
Newsgroups: comp.arch,comp.benchmarks
Subject: Re: Source of SPEC b'marks (was Re: need ftp )
Date: 2 Oct 92 15:15:32 GMT
Followup-To: comp.benchmarks
Organization: Intel Corporation, Santa Clara, CA USA

In article <1992Oct1.142704.18580@ryn.mro4.dec.com> bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:
>
>In article <BvF48t.30u@inews.Intel.COM>, jwreilly@mipos2.intel.com (Jeffrey Reilly) writes...
>> 
>>And again, for information or obtaining the benchmark suites,
>>SPEC can be contacted at:
>> 
>>SPEC				Phone: 703-698-9600 ext 318
>>c/o NCGA			Fax: 703-560-2752
>>2722 Merrilee Drive, Suite 200
>>Fairfax, Va 22031-4499
>> 
>SPEC Release 1.2b tape costs $300. Since it contains the makefiles for many
>different vendors, it is the easiest way of getting the benchmarks to run.
>
This is incorrect. The SPEC Release 1.2b tape is now priced at $1000. SPEC
changed the price to encourage vendors and users to use the
newerbenchmark suites CINT92 and CFP92. Both CFP92 and CINT92 also
include makefiles for the SPEC member vendors.

Jeff
SPEC Release Manager for CINT92/CFP92
 
Jeff Reilly			| "There is something fascinating about
Intel Corporation		| science. One gets such wholesale returns
jwreilly@mipos2.intel.com	| of conjecture out of such a trifling
(408) 765 - 5909		| investment of fact" - M. Twain
Newsgroups: comp.arch
From: fpj@ingrina.inesc.pt (Fernando Pereira Jesus)
Subject: Re: implementing random replacement
Organization: INESC (Inst. Eng. Sistemas e Computadores) Lisboa, Portugal
	<FPJ.92Sep28171144@ingrina.inesc.pt> <BvCpp2.EFt@metaflow.com>
Date: Wed, 30 Sep 1992 16:02:28 GMT

In article <BvCpp2.EFt@metaflow.com> rschnapp@metaflow.com (Russ Schnapp) writes:

>   |> Aditionaly, the shift register stops at empty (flushed) lines, thus
>   |> ensuring that empty lines are used before lines allready in use.
>
>   It seems to me that this would not "ensure" that unused lines are
>   pressed into service before valid lines are replaced.  There is no
>   guaranteed time before the random pointer has scanned all values.  The
>   time to scan all lines is probabilistic.

The time to scan all lines in the cache is (more or less) 10ns * N
N is the number of lines in the cache. If N is, say, 100, it will take
1us to scan all lines. If this time is to high, or if N is a large
number, you can have two levels of counters: (a tree of counters) the
root level counter selects one of the second level counters which
selects a cache line (in most cases large caches are internally
splited to decrease response time, so this is easy).

>   Using a simple counter has two advantages:  1) You can guarantee that
>   all lines will be scanned in a finite amount of time (granted, this is
>   probably just a nit-pick);
I can't see your point. With our shift register all lines will be
scanned in a finite amount of time, and since it runs assynchronously,
it will be faster than a simple counter.

>                              and 2) You can add a fence register to
>   protect some lines from replacement.  When the counter matches the
>   fence register, you reset it.  This is nice if you want to lock certain
>   lines into the cache.
In our design, this is possible to. With a few more transistors, it
is possible to make the "set" and "reset" signals skip over one stage,
so if on line is marked not to be replaced, the counter will not scan
this line.

>   |> PS: My english is bad, but if I wrote it in Portuguese you probably
>   |>     wouldn't understand a word :-) !!
>
>   Hey, your English is lots better than my Portugese.  You're doing just
>   fine.

Maybe I was lucky... :-)

--
   _____                  _ __   ___            
    /  '             /   ' )  ) '  /            Fernando Pereira Jesus
 ,-/-_ _ _  _  _  __/__   /--'  __/-_ _     _   Telef : +351.1.3100282
(_/ (~/ / )(_|/ )(_/(_)  /     / / (~/_)(_// )  e-mail: fpj@inesc.pt
     ___________________/_____(_/___________/   
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Organization: Digital Equipment Corporation
Date: 29 SEP 92 10:08:48    


In article <1992Sep29.011230.3232@odin.corp.sgi.com>, mash@mash.wpd.sgi.com (John R. Mashey) writes...
> 
>The R4000 chip is every bit as 64-bit as Alpha is.  Both have 64-bit
>integer
>registers, 64-bit adders, and 64-bit data paths.  
> 

I agree.

/d