HDTenEightyP/NetNews huggingface dataset:
From: borasky@ogicse.ogi.edu (M. Edward Borasky)
Newsgroups: comp.arch
Subject: Re: One Instruction Computers
Date: 6 Oct 92 18:17:11 GMT
Article-I.D.: ogicse.43715
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR

In 1962, this was a common exercise for undergraduate programming 
students.  Essentially, you design a CLASSICAL von Neumann machine --
self-modifying code is not only allowed but NECESSARY for loops, 
indexing, etc. -- like the IAS machines.  The only instruction is a two-
address one: subtract location 's' from the accumulator and branch to
'b' if negative.  Registers need to have addresses; you have to clear a
register by subtracting it from itself.  Two's-complement is used to 
test for zero -- if a number's postive and its twos-complement is 
positive, it's zero.  It's quaint, but it works.  I/O is memory-mapped,
of course!

Let's update this exercise for TODAY'S students.  My question is, for 
all you Hennessy and Patterson readers out there: suppose we actually 
BUILT such a beast.  Update the technology to be the fastest available 
(say, GaAs) and use 1990s address and data widths (let's say 64-bit 
twos-complement data path and 32-bit addresses).  Recognizing that it's
going to take several cycles to do simple things like stepping through 
an array, calling a subroutine, manipulating stacks, etc., and that 
niceties like multiplies, floating point arithmetic, string collating 
sequence compares, etc. take HUNDREDS or THOUSANDS of cycles, what does
the cycle time of such a machine have to be to be as fast as an IBM 
PC/AT with co-processor on Lotus 1-2-3?
Xref: sparky comp.arch:9689 comp.lang.misc:3184
From: desj@ccr-p.ida.org (David desJardins)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 29 Sep 92 00:10:21 GMT
Organization: IDA Center for Communications Research, Princeton

Burkhard Neidecker-Lutz <neideck@nestvx.enet.dec.com> writes:
>> All stores on the DEC Alpha (the processor which I mentioned at the
>> beginning of this thread) cost many cycles, because current
>> implementations have write-through cache.

> Not (quite) true. 

Every store (with very rare exceptions) sooner or later is going to cost
you memory cycles.  Now I suppose that it is true that if your memory is
fast enough AND your writes small enough (32 instead of 64 bits) AND you
do all of your writes in cache-line-sized blocks, then you might not be
memory-bound.

> When you do a write to a block which isn't already in the write
> buffer, it allocates one of these blocks and places your write into
> it. Bt it will *not* blindly write it out (unless some conditions are
> met), but rather wait for more writes into the same block, merging as
> many writes into the same block (i.e. 8 word writes to all of the
> words in a block will eventually fill all of it without necessarily
> causing any external write activity.)

But it's still the case that every word written has to eventually be
flushed out to memory.  Except, I suppose, in the very rare case that
you write that same word again before it reaches the head of the write
buffer queue.  Whereas with a write-back cache, you can do an arbitrary
number of writes and reads of the same word with no memory traffic, as
long as you don't ever need to overwrite the cache entry.

>> Additionally, read hits on the contents of the write buffer can have
>> unpleasant effects.  I think all of the write buffers have to be
>> flushed.  Thus reading in your spilled registers too quickly can be
>> expensive.

> A write in the 21064 goes to the cache as well as to the write buffer,
> hence as long as there is no load miss no flush is needed.  This is
> one of the not so obvious benefits of the relaxed memory ordering in
> the Alpha.

I assume that this can only happen if the cache line you write to is
already loaded in the cache.  If you write to a currently noncached
line, then read that word back in, you would have to flush the write
buffer to memory and then reread the cache line from memory.  Right?

It's certainly true that you should be able to diminish the probability
of this by being very careful and clever about reusing the memory used
for register spills.  So that it is usually present in cache.  In fact,
you might even want to put in redundant loads before stores; if the
cache line is already loaded, these won't cost anything, and if it's
not, then you want it to be.

                                        David desJardins
Newsgroups: comp.arch
From: davew@willow03.cray.com (Dave Wagner)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Originator: davew@willow03
Organization: Cray Research, Inc.
Date: 28 Sep 92 10:48:57 CDT


In article <14813@auspex-gw.auspex.com>, guy@Auspex.COM (Guy Harris) writes:
> There's an interview with Roger Ross of in the latest Open Systems
> Toady(sic) in which, among other things, he's quoted as saying:
> 
> 	The only real 64-bit processor out there is Alpha.  The MIPS
> 	chip is not a 64-bit machine -- not the way I measure it.  And
> 	neither are the rest and neither is SPARC.  All of them have
> 	attributes of 64-bit-wide widgets, which makes sense from a
> 	bandwidth standpoint.  But a true 64-bit machine has 64-bit
> 	registers, 64-bit adders, quad multipliers.  Only Alpha has
> 	that.  The present machines are merely 32-bit machines that
> 	implement 64-bit paths.

Check address spaces in Alpha though.  Alpha (21064) has only a 43-bit virtual
space, and a 34-bit physical space.  I think a 'real' 64 bit processor should
provide more (64bits) of both.
-- 
Dave Wagner                                     Cray Research, Inc
davew@cray.com , uunet!cray!davew               655F Lone Oak Drive
(612) 683-5393                                  Eagan, MN  55121
Newsgroups: comp.arch
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: Re: No special branch/jump formats?
Organization: Curtin University of Technology
Date: Wed, 30 Sep 1992 17:25:48 GMT

In article <1824@sousa.ltn.dec.com>, supnik@human.enet.dec.com (Bob Supnik) writes:
> Sorry to omit the originals, but some comments on the whole thread:
> 
> 1. PC as general register in VAX's.  While the architecture spec says that
>    direct references to PC are 'unpredictable', the preferred implementation
>    is to fault on such references.  If a fault was not generated, the
>    implementation would produce a garbage value on read, and throw a write
>    into the bit bucket.  This is because the PC could not be kept in the
>    main register file; it had to be implemented with special incrementing
>    hardware somewhere in the main instruction decoder.  A read or write
>    to 'R15' would access the 16th register in the register block, typically
>    a microcode temporary of no redeeming social importance.
> 

To add the cannonical example, which will bring a smile to Bob, I'm sure, is the
11/70. It had *RIGHT* shifts done in a shift tree between the ALU and GR file,
left shifts were done in the ALU. The REAL PC was kept in PCA and PCB, not R7
in the GR blocks. The fun bit, was that the input to PCA came from between
the ALU and the Shift-tree. Hence a ASL PC would jump the CPU, but a ASR PC
would generate a reload of the unshifted PC and a garbage write to R7. DEC
diags actualy used this to detect KB-11 processors.

~Paul
From: morioka@hrlgw92.hrl.hitachi.co.jp (Michio Morioka)
Newsgroups: comp.arch
Subject: Papers on snoop cache coherence features by SPLASH benchmark
Date: 2 Oct 92 01:30:33 GMT
Organization: Hitachi Research Lab., Hitachi, Ltd., Japan

Hi, forks,

Are there any papers on the evaluation of cache coherence transactions
for the shared-memory/shared-bus (snoop cache coherence) multiprocessor
by Stanford SPLASH benchmarks.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^

Thank you in advance for your advice.

------------------------------------------------------------------------
Michio Morioka                         Hitachi Research Lab.
                                       Hitachi Ltd.,
------------------------------------------------------------------------
Newsgroups: comp.arch
From: tg@utstat.uucp (Tom Glinos)
Subject: Re: Roger Ross... [really: why there may not be anything after micros]
Organization: University of Toronto, Dept. of Statistics
Date: Thu, 1 Oct 1992 13:54:26 GMT

In article <1992Oct1.005921.12288@odin.corp.sgi.com> mash@mash.wpd.sgi.com (John R. Mashey) writes:
>	c) Micros have mostly wiped out minis and superminis, in the sense
>	that even supermini architectures in big boxses have their CPUs
>	implemented as microprocessors, not as multiple boards of logic.
>	d) Micros have *not* wiped out mainframes in the same way ...
>	however, there are quite a few people building systems with micros
>	that look more like high-end superminis or low-end mainframes in
>	memory sizes, CPU performance, I/O transfer rates ... and working on
>	I/O connectivity.

John's market perceptions, are of course, pretty good.
Most major mainframe vendors have noticed decreased revenue from their
hardware lines and beginning to get worried about it.

The elimination of the supermini brings about another interesting
question. Will the concept of a "Departmental Server" also disappear?
Does it deserve to survive, if so, why?
-- 
=================
No regrets, ever!			| Tom Glinos @ U of Toronto Statistics
For down that path, lies madness.	| tg@utstat.toronto.edu
From: rhiller@cbnewsj.cb.att.com (ronald.g.hiller)
Newsgroups: comp.arch
Subject: SPARC Version 9 spec
Keywords: SPARC
Date: 6 Oct 92 17:43:56 GMT
Distribution: na
Organization: AT&T

I would like to know how I can get a copy of the latest SPARC 
architecture specification...Version 9.  This includes information
on the 64 bit architecture for SPARC processors.  Any information
would be appreciated.

Thanks,
Ron Hiller
ron@ho1focus.att.com
Newsgroups: comp.arch,comp.lang.misc
From: neideck@nestvx.enet.dec.com (Burkhard Neidecker-Lutz)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: CEC Karlsruhe
Date: Mon, 28 Sep 92 08:44:59 GMT

In article <1663@idacrd.UUCP> desj@ccr-p.ida.org (David desJardins) writes:
>All stores on the DEC Alpha (the processor which I mentioned at the
>beginning of this thread) cost many cycles, because current
>implementations have write-through cache.  So you actually have to
>perform a memory cycle for every one of these.  Assuming your
>computation is memory-bound, as most are, that's a very substantial
>cost.

Not (quite) true. The 21064 does have a write-through cache on the
chip, but it makes use of one of the architectural differences
between the Alpha and other machines, namely the fact that it
doesn't need to preserve write-ordering (unless specifically ordered to).

I would call the 21064 cache a "delayed-write-through" cache. It
has 4 blocks of 32 bytes each and maintains them as a queue. When
you do a write to a block which isn't already in the write buffer,
it allocates one of these blocks and places your write into it. Bt
it will *not* blindly write it out (unless some conditions are met),
but rather wait for more writes into the same block, merging as many
writes into the same block (i.e. 8 word writes to all of the words
in a block will eventually fill all of it without necessarily causing
any external write activity.)

>Additionally, read hits on the contents of the write buffer can have
>unpleasant effects.  I think all of the write buffers have to be
>flushed.  Thus reading in your spilled registers too quickly can be
>expensive.

A write in the 21064 goes to the cache as well as to the write buffer,
hence as long as there is no load miss no flush is needed. This is one
of the not so obvious benefits of the relaxed memory ordering in the 
Alpha.

		Burkhard Neidecker-Lutz

Multimedia Engineering, CEC Karlsruhe	   EERP Portfolio Manager
Software Motion Pictures		   Multimedia Base Technology
Digital Equipment Corporation
neidecker@nestvx.enet.dec.com
Newsgroups: comp.arch,comp.lang.misc
From: izahi@bsc.no (Raul Izahi Lopez Hernandez)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Summary: A Modular Architecture is the solution 
Keywords: Modular Architectures
Organization: Bergen Scientific Centre, Bergen, NORWAY
Date: Mon, 5 Oct 1992 07:49:46 GMT

In article <BvF75z.GBA@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
>In article <1992Sep29.232852.22456@CS.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
>>In article <Bv1G5B.AGn@mentor.cc.purdue.edu>
>>hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>>>In article <1992Sep22.212534.14185@CS.ORST.EDU>
>>>crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
>>>>As near as I can tell, your buffer is only present to provide a cache of
>>>>values and is not important to the correct operation of the algorithms.  As
>>>>such, it is a separable issue and I will separate it.
>
>>>Your assessment is correct.  While it is not important to the correct 
>>>operation of the algorithms, it is extremely important to the running time,
>>>especially on parallel processors.
>
>>Independence of computations is more important to the execution time on
>>parallel processors than is a fast buffer.  A shared buffer, no matter how
>>fast, will eventually limit performance.
>
>I said nothing about a shared buffer.  However, there are places where a
>fast shared buffer can improve performance.  I hope that each processor
>has enough memory for its own buffer.  If not, performance is likely to
>be greatly reduced.

   What we need to introduce in the computer industry is Modular Architectures.
   If for a certain application you need more buffer space, you add one or
two more 'buffer chips'. If you need more registers you add more 'register
chips', if you need another floating point unit, say a true 256-bit multiplier,
you call the salesman and ask for a '256-bit FP multiplier chip' that you
plug into one of the sockets in your motherboard and have the compiler
generate a separate stream of code for it for the operations that include
the variables declared as real*32.
   The on-board performance monitors would tell you where are the bottlenecks
in your code execution that need relief.


-- 
         -----> All opinions expressed here are my own, not IBM's <-----
Raul Izahi Lopez	Izahi Engineering
izahi@bsc.no		IBM Bergen Environmental Sciences and Solutions Centre
			Thormoehlensgate 55, 5008 Bergen, NORWAY (47-5)54-4653
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.arch
Subject: Re: No special branch/jump formats?
Date: 30 Sep 92 10:39:44 GMT
Organization: Department of Computer Science, U of Copenhagen

mshute@cs.man.ac.uk (Malcolm Shute) writes:
> MOV @(R3),PC also has no equivalent, and is enormously useful,
>                     especially if you are wanting to build a jump
>                     table... in effect you have an address with 3
>                     levels of indirection.

As Roger Ivie wrote, JMP (and JSR) leave out one level of indirection
--- or rather, they cause the next instruction to be fetched from the
same address where MOV would fetch the word to be moved. Of course,
this leaves some cases of MOV <X>,PC that do not have an equivalent
JMP <Y>, and vice versa; but some of those cases can be simulated:

	MOV @(R3),PC	becomes	JMP @0(R3)	--- one location more
	MOV @#LBL,PC	becomes	JMP LBL		--- may need relocation
	JMP R0		is not allowed, anyway
	JMP #INST	becomes	TEST PC		--- the JMP is not very useful
				INST
	JMP LBL		becomes	ADD #(LBL-.),PC	--- subtract 2 or 4,
						--- depending on your assembler

This leaves the cases @(R3)+, @-(R3), @OFF(R3), @LBL for <X>, and
(R3)+, -(R3), OFF(R3) for <Y>, that cannot be simulated with one
instruction.

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
Newsgroups: comp.arch
From: sef@kithrup.COM (Sean Eric Fagan)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Organization: Kithrup Enterprises, Ltd.
Date: Sun, 27 Sep 1992 19:52:03 GMT

In article <Bv8tzG.Kv1.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>I count four:
>- Alpha  (which is about to be named VRX or some such??)
>- R4000
>- Ncube-2 node processor, I think
>- KSR-1 node processor (actually they only implemented 40 bits)

I could have sworn that the Cray, CDC 180-state (e.g., Cyber 995), and a
couple of other supercomputers all had 64-bit registers and company.  (If
you're going bring in the ksr-1... :))

-- 
Sean Eric Fagan  | "You can't get lost in one room, no matter how
sef@kithrup.COM  |  little effort you make to learn your way around."
-----------------+    -- William E Davidsen (william@crd.GE.COM)
Any opinions expressed are my own, and generally unpopular with others.
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Followup-To: comp.arch
Organization: Intel Corp., Hillsboro, Oregon
	<ADAMS.92Sep26174101@PDV2.pdv3.fmr.maschinenbau.th-darmstadt.de>
	<1992Sep26.204430.29763@odin.corp.sgi.com> <7414@charon.cwi.nl>
Date: Mon, 28 Sep 1992 00:12:17 GMT

    In article <1992Sep26.204430.29763@odin.corp.sgi.com> mash@mash.wpd.sgi.com (John R. Mashey) writes:
     > For example, to pick a common example of using a 1-level indirect
     > scheme (as in VAX, for example), one would compile a call by reference
     > into passing a pointer on the stack.  To get the value, one would use
     > indirect reference, i.e.:
     > 	LOAD	R1,@N(SP)	(or something like that)
     > and later, when you need it again:
     > 	LOAD	R2,@N(SP)	(or something like that)

    [Dik T. Winter]:
    I doubt even that that single instruction will be much faster than the
    two instruction sequence (alas, DEC does not provide timing information):
	    LOAD    R1,N(SP)
	    LOAD    R1,(N1)
    It can be made faster (I think, but I am not a hardware designer), but my
    off the cuff opinion is that the two instruction sequence allows the optimizer
    more freedom spacing the load instructions with computational instructions on
    pipelined architectures.  

I'm jumping into the middle of this... I'm not sure about the assembly
language notation, but I assume that we are comparing:

    r1 := load( sp )
    r1 := load( r1 )

to a single instruction that performs the indirection 

    r1 := load( load( sp ))


There are only a few reasons that I know of to create an indirect
memory addressing mode:

(1) (Macro) Instructions are expensive

    {Probably not applicable to modern processors}

(2) The indirection needs to be performed atomically
    wrt interrupts on the local processor (a concern for some LISPish
    machines.)

(3) Indirect addressing is used very often, in circumstances that cannot
    be removed by optimizers (e.g., because of asynchronous garbage
    collection, as above).

    This reason only applies if the use is common enough that you anticipate
    creating a special cache structure to optimize indirect addressing
    (e.g. a cache that associates on the address of the pointer,
    not the contents of the pointer).



    
--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
From: butrfeld@swift.cs.tcd.ie
Newsgroups: comp.arch
Subject: RE: One Instruction Computers
Date: 1 Oct 92 16:17:51 GMT
Organization: Computer Science Department, Trinity College Dublin

dinda@cae.wisc.edu (Dinda Peter) asks:

> Prevoiusly someone had posted am message regarding one instruction
> computers - I believe a 3 operand conditional subtract instruction.
> I believe there was also a pointer to a paper that had been written
> on the subject.  Please email.

Could you let me know as well ? Thanks,
					Andrew Butterfield
					butrfeld@.cs.tcd.ie
From: m-jk8594@GRANNY.CS.NYU.EDU (James Kyriannis)
Newsgroups: comp.arch
Subject: nCube Machine
Date: 30 Sep 92 01:45:45 GMT
Organization: Courant Institute, New York University

I know this may not be quite in the scheme of what is being discussed here,
but I felt this newsgroup would target the appropriate people.  Does anyone
know where/how I can get the poster for the nCube machine?  It says something
like:

"The world's fastest machine: nCube 50,000 MIPS"

along with a picture of the machine.


Please reply via e-mail.

Jimmy Kyriannis
m-jk8594@cs.nyu.edu
 
Newsgroups: comp.arch
From: martyi@nubbins.wpd.sgi.com (Marty Itzkowitz)
Subject: Re: What was the intended advantage of using 36bits CPU?
Reply-To: martyi@sgi.com
Organization: Silicon Graphics, System Software Division
Date: Mon, 5 Oct 1992 16:01:38 GMT

In article <MOSS.92Oct5095425@CRAFTY.cs.umass.edu>, moss@cs.umass.edu (Eliot Moss) writes:
|> 
|> The questions was: Why 36 bit words instead of 32 or 48? One respondent
|> mentioned that 6 bit character codes were popular at the time, so multiples of
|> 6 were popular (versus the current "standard" of multiples of 8 and/or powers
|> of 2). Octal was also popular, so multiples of 3 were around, but I doubt that
|> was a strong reason. Rather, based on the earlier heritage of 18 bit machines,
|> I suspect there was a feeling that 18 bits of address space was large enough,
|> and the 36 bit machines were built partly so that one word could hold one Lisp
|> cons cell (car and cdr both an address in size, hence 2 x 18 = 36 bits). By
|> the time of the DECSystem 20 the address space was getting tight, but the
|> architecture came from many years before. These days we might see some folks
|> use 64 bit words in a similar way ....
|> --

Actually, car and cdr are acronyms for "Contents of Address Register" and
"Contents of Decrement Register", from their original use on the IBM 7090.
The 7090 had a 36-bit word, but the word was divided into 3-bits of op code,
15 bits of decrement, 3 bits of tag, and 15 bits of address, not 18 bits
each for two addresses.  There were instructions to read and write the
various fields within a word, so using the address and decrement fields
was quite simple.

I believe the original LISP implementation used the tag field also.

	Marty Itzkowitz
From: ojuarez@mtecv2.mty.itesm.mx (Octavio Juarez Espinosa)
Newsgroups: comp.arch
Subject: About alpha chip
Summary: help
Keywords: Looking information
Date: 30 Sep 92 13:30:26 GMT
Article-I.D.: mtecv2.6077
Organization: I.T.E.S.M. Campus Monterrey



Hi,

I'll appreciate if you send me information about alpha chip.

Thanks in advance.

Sincerely,

Octavio Juarez
ojuarez@mtecv2.mty.itesm.mx

-- 
Octavio Juarez Espinosa
Gabriel Valerio 1134 
Saltillo, Coahuila    CP 25000
Mexico  email ojuarez@mtecv2.mty.itesm.mx
Newsgroups: comp.arch
From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin)
Subject: Re: Roger Ross... [really: why there may not be anything after micros]
Organization: College of Marine Studies, U. Del.
Date: Fri, 2 Oct 1992 12:41:39 GMT

In article <1992Oct1.135426.17400@utstat.uucp> tg@utstat.uucp (Tom Glinos) writes:
>In article <1992Oct1.005921.12288@odin.corp.sgi.com> mash@mash.wpd.sgi.com (John R. Mashey) writes:
>>	c) Micros have mostly wiped out minis and superminis [....]
>>	d) Micros have *not* wiped out mainframes in the same way ...
>
>The elimination of the supermini brings about another interesting
>question. Will the concept of a "Departmental Server" also disappear?
>Does it deserve to survive, if so, why?

There are some good reasons to believe that the "Departmental Server"
will actually become more widespread rather than less.   

Of course the actual machine will be a rather standard micro, but the
economies of central administration coupled with the performance of X
terminals make this model rather appealing in many environments.   

As popular DOS (ugh) software is becoming much more available for
reasonable cost in UNIX environments, the largest (but not the only)
barrier to migrating people off of pc's and onto departmental servers
is disappearing.
-- 
--
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