HDTenEightyP/NetNews huggingface dataset:
From: wilson@schaefer.math.wisc.edu (Bob Wilson)
Subject: Re: What was the intended advantage of using 36bits CPU?
Organization: Univ. of Wisconsin Dept. of Mathematics
Date: Mon, 5 Oct 92 18:17:56 GMT

parke@star.enet.dec.com (Bill Parke) writes:


>In article <869@felix.Sublink.Org>, eb@felix.Sublink.Org (Enrico Badella) writes:
>|>Path: nntpd.lkg.dec.com!news.crl.dec.com!deccrl!decwrl!sdd.hp.com!swrinde!gatech!rutgers!modus!dyna!osra!felix!eb
>|>From: eb@felix.Sublink.Org (Enrico Badella)
>|>
>|>Recently I came hold of and old paper that described the TENEX Operating
>|>System for old DEC Systems 10 and 20; I never used or saw such beasts but
>|>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?
>|>
>|>-- 
>|>Enrico Badella				Internet: eb@felix.sublink.org
>|>Soft*Star s.r.l.			          eb@icnucevx.cnuce.cnr.it
>|>Via Camburzano 9			Phone:    +39-11-746092
>|>10143 Torino, ITALY			Fax:      +39-11-746487
>|>

>4 (decimal) , 12, 18 and 36 bit computers from DEC, IBM and others (including
>the ones complement UNIVAC 11xx series) predated 32 bit and 16 bit machines
>by a number of years.

>In that context, TENEX is a relativly "modern" operating system (to which
>some have yet to catch up).  The ancestor of U*X MULTICS ran on a GE
>processor which I believe was also a 36 bit machines.

>None of these had anything to do with Open systems at the time (late 50s
>to early 70s).  Open and portable at that time was a good FORTRAN/COBOL/
>LISP/... compiler.

>Bill Parke 			parke%star.enet.dec@decwrl.dec.com
>VMS Development			decwrl!star.enet.dec.com!parke
>Digital Equipment Corp		parke@star.enet.dec.com
>110 Spit Brook Road ZK01-2/D59, Nashua NH 03063

>The views expressed are my own.
Besides, what was the advantage at that time of a word length which
was a multiple of 8? There was no agreed upon character coding scheme
of that length (IBM's EBCDIC was 12 bits, CDC used 6 bits, ...) and
machines rarely had instructions for working on pieces of a word as a
data item except where it had relevance to the instruction set, as for
example the ability to deal with the piece of a word which would be an
address if executed.
As to the time vs the cost of hardware, there were 48 and 60 bit
machines as well as 36 bit well before 2^n took over.
Bob Wilson
wilson@math.wisc.edu
Newsgroups: comp.arch
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 5 Oct 1992 22:07:32 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


In article <1992Oct5.141706.25648@terminator.cc.umich.edu> sarr@sinshan.citi.umich.edu (Sarr J. Blumson) writes:

>The 10 and 20 had 36 bits because the IBM 704 (1955 or so) did.  Back
>then everybody thought 6 bit characters were plenty; 36 was a
>reasonable hardware compromise for roughly the same reasons 32 is.  18
>and 24 bit machines were also common, and there were some 30s.

And the IBM 701 had 36 before that.  A big reason for the popularity of
36 is that is has more divisors than any nearby number (1,2,3,4,6,9,12,18)
When all the memory you have is 1024 words you have to pack smaller things
into words; and more different sizes of things will fit into 36 bit
words with no waste space than will fit into any nearby word size.

Some of the hand-built machines in the nuclear research community had
40 bit words; so I presume the scientists using them considered that
to be sufficient precision for their work, in the days before floating
point was built into hardware.  To make use of such a wide word for
instructions you would either pack 2 or 3 instructions per word (as the
IBM 701, but not the 704 did) or design instructions with 2, 3, or 4
addresses.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle

Xref: sparky comp.arch:9677 comp.lang.misc:3182
From: cliffc@rice.edu (Cliff Click)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 28 Sep 92 16:10:23 GMT
Article-I.D.: athene.CLIFFC.92Sep28101023
	<1992Sep24.235308.18105@odin.corp.sgi.com> <1661@idacrd.UUCP>
	<ADAMS.92Sep25172127@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
	<CLIFFC.92Sep25182902@helena.rice.edu>
	<MEISSNER.92Sep26083045@curley.osf
Organization: Center for Research on Parallel Computations

In article <CLIFFC.92Sep25182902@helena.rice.edu> cliffc@rice.edu
(Cliff Click) writes:

| In short, fast code avoids memory whenever possible.  A fast int<->float 
| register path lets the compiler "spill" to the other register set when the
| current one gets full.  

In article <MEISSNER.92Sep26083045@curley.osf.org> meissner@osf.org 
(Michael Meissner) writes:

| On the other hand, things can get VERY hairy if you spill integer
| registers to FP registers in kernel or standalone code.  For example,
| consider what happens if the compiler decides to do one of these
| spills in the init sequence of the kernel, before the FP unit has been
| initialized yet, [... other example omitted...]

Then either your compiler or kernel-makefile is broken, because you need to
compile code WITHOUT using the FP regs, and that should be a compiler option.


(Cliff Click) writes:
| Bad: Writing to memory requires you to have a pointer to a spill location 
| handy.  Sometimes due to local storage requirements and other temps 
| generating a stack frame offset takes 2 or more instructions.  Thus the store
| to cache might take 2 instructions (cycles) to set up, and 2, possibly 3
| more cycles to do the store. 

(Michael Meissner) writes:
| I think it is rare that spilling would require more than 1 instruction
| to store and load.  ... 

Rare, but must be handled.  And some of my test cases did require it.

| On the MIPS, you would have to
| have a stack frame that is more than 32K (64K for 88k), in order to
| open up the possibility that the spill would generate more than 1
| instruction (or unload the stack/frame pointer).  

On the Sparc, 4K is the limit.
In any case, I compile Fortran, land of humongous arrays where 32K is small.

| If a compiler was
| worried about this, it could rearrange the stack, such that the large
| arrays would get allocated at the high end of the stack, and group the
| spills closer to the stack/frame pointer.

Yes, but when the stack got rearranged some array base which was at a 
convenient offset from the stack pointer now requires an extra register
for offset calculations.  Which in turn screws up your register allocation
and stack frame size.  Bleah.
I fixed it on the Sparc by putting spill code next to the stack pointer, and
addressing arrays from the frame pointer (Sun's OS disallows unloading the
frame pointer, it must be live on interupts for the window spills).

Cliff
cliffc@cs.rice.edu
--
The Sparc ABI had the most brain-damaged calling convention I've ever seen.
It's probably better now but reminiscing gives me something to complain about.
Cliff Click (cliffc@cs.rice.edu)  |  Disclaimer:  My lawyer made me say it.
From: cprice@mips.com (Charlie Price)
Newsgroups: comp.arch
Subject: Re: Fully associative cache
Date: 2 Oct 92 23:11:05 GMT
Organization: MIPS Technologies, Inc
NNTP-Posting-Host: lloyd.mti.sgi.com

In article <1992Oct1.130541.29213@odin.diku.dk> thorinn@diku.dk (Lars Henrik Mathiesen) writes:
>cprice@mips.com (Charlie Price) writes:
>>For a read, both the tag and data sides are read at the same time.
>>For a write:
>> the tag side is read to check for a cache hit/miss,
>> the data for the write goes into a couple-deep store buffer,
>> the oldest pending write in the store buffer is written
>> to the appropriate line in the data side.
>
>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.  You need a couple
of entries if you are going to do these at the same time.

>In a write-back cache, what happens if a read causes the cache line
>where the buffered entry belongs to be replaced? One extra cycle of
>delay to update the line before writing it back, I'd guess.

If there is only one entry in the store buffer it doesn't
delay processing (there is an otherwise-idle cycle for the
data side of the data cache).
In the case of the R4000, the displaced primary line that will
be written back is read out of the Dcache into a writeback buffer
and the writeback to secondary cache (or memory if you have a PC part)
is done after the refill access to Scache (or refill from memory).
-- 
Charlie Price    cprice@mti.sgi.com        (415) 390-4457
SGI (MTI) / MS 10U-178 / 2011 N. Shoreline Blvd / Mountain View, CA   94043   
From: kenb@hpindda.cup.hp.com (Ken Brown)
Date: Mon, 28 Sep 1992 17:22:18 GMT
Subject: Re: Which is the Best RISC Arcitecture ?
Organization: HP Information Networks, Cupertino, CA
Newsgroups: comp.arch

/ hpindda:comp.arch / torbenm@diku.dk (Torben AEgidius Mogensen) /  1:21 am  Sep 25, 1992 /
mjohnson@netcom.Netcom.COM (Mark Johnson) writes:

>In article <1992Sep24.180118.1392@sun1.ruf.uni-freiburg.de> wolf@sun1.ruf.uni-freiburg.de (Klaus H.Wolf) writes:
>    > (I know SPARC, MIPS, 88k, POWER, DSP96002)


>To those, add
>     Clipper    (Intergraph)
>     Precision  (Hewlett Packard)
>     Swordfish  (National Semiconductor)
>     i860       (Intel)
>     i960       (Intel)
>     ARM        (Acorn / VLSI Technology)
>     Regulus    (Computer Consoles Inc)
>     Lightning  (Metaflow / LSI Logic)
>     Pinnacle   (Ross Tech / Cypress)
>     Ice        (NEC / MIPS)


HP precision architecture may not be available outside HP.

The ARM in its present form has no FPU, so it would not fit the
requirements of maximum FLOPS. However, the FPU should be out "real
soon now", so you may look at it anyway. Also, the ARM is no longer
Acorns Risc Machine, but Advanced Risc Machine and is owned by ARM
ltd. and produced by several sources, including VLSI tech. It's main
advantages are low price, low power consumption and regular design.

You may add the Transputer to the list. Some may argue that it isn't a
RISC, but that depends on your definition. The Transputer is designed
for use in parrallel systems, and the T9000 has quite good floating
point capability.

The new SuperSPARC from TI is supposed to have tremendous floating
point speed, but it may well be far to expensive for a multiprocessor
system.

	Torben Mogensen (torbenm@diku.dk)
----------
Xref: sparky comp.arch:9660 comp.lang.misc:3179
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 27 Sep 92 00:32:42 GMT
Followup-To: comp.arch
Organization: CWI, Amsterdam

In article <1992Sep26.204430.29763@odin.corp.sgi.com> mash@mash.wpd.sgi.com (John R. Mashey) writes:
 > In article
 > <ADAMS.92Sep26174101@PDV2.pdv3.fmr.maschinenbau.th-darmstadt.de>,
 > adams@pdv3.fmr.maschinenbau.th-darmstadt.de (Adams) writes:
<about double indirections>
 > 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)
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 think this even holds if only a single
reference is made to the variable.  (And of course, as John Mashey notes,
with the current large register sets to tie a register is much less a problem
than on the VAX.)

 > 1) At one time or another, many computer architectures included
 > indirect-addressing, hence computer designers are quite familiar with it.
True.  Because when indirect-adressing is provided it makes it simpler for
the compiler writer, because many hll constructs map naturally to
indirect-adressing.  And we know that following the path of making it
simpler for compiler writers leads to disasters like the 432.  But there
were significant architectures that never did include indirect-addressing.
The CDC 6600 amongst others.
 > 
 > 2) With the sole exception of the 68000->68020 transition, I cannot think
 > of a major computer architecture done in the last 10 years that
 > included indirect addressing, and none at all that permitted multi-level
 > indirect addressing (or the PDP-10 sort).  I.e., CPU designers
 > have voted this feature down....  no matter how nice it may seem.
Perhaps not major (only at some time).  But the NS 32k:
        MOVW     4(8(FP)),4(12(FP))
done in the last 10 years.  There is even a reasonable C construct that
maps to this (think pointers to structures and copying one to the other)!
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
Newsgroups: comp.arch
From: rfarias@lascar.puc.cl (Ruben Farias IIC)
Subject: URGENT: NCR tower 386
Organization: Pontificia Universidad Catolica de Chile
X-Newsreader: Tin 1.1 PL5
Date: Tue, 29 Sep 1992 17:58:18 GMT


Newsgroups: comp.arch
From: gokhale@wucs1.wustl.edu (Aniruddha Gokhale)
Subject: Looking for Topic for Project
Organization: Washington University, St. Louis MO
Distribution: na
Date: Sun, 27 Sep 1992 19:14:43 GMT

Hello Everyone :

I am a CS graduate student at Washington University, St. Louis and am 
looking for a topic for a term project for the Computer Architecture course.

The term project is to be done in a group of three and would be around
two and a half month duration.

We have to choose among the following general areas :

1) Classical Machine Architecture Problems
2) Advanced or Novel Computer Architecture
3) Specialized Processors and Architecture/Algorithm Mapping
4) Modelling and Simulation Computer Architectures

I would appreciate if anyone could send me any ideas.

Please send me your replies at 
          gokhale@wucs1.wustl.edu


Thanks in advance

Aniruddha Gokhale
-----------------------------------------------------------------------
Dept of Computer Science		Phone : (314) 935-7533
Washington University
St. Louis, MO 63130
-----------------------------------------------------------------------
-- 
Aniruddha Suresh Gokhale                Internet : gokhale@cs.wustl.edu
Office   Dept of CS, Washington Univ    Home  : 6164 Pershing Ave # E
         St. Louis, MO 63130-4899               St. Louis, MO 63112
Phone : (314) 935-7533			Phone : (314) 863-4235
From: mash@mash.wpd.sgi.com (John R. Mashey)
Newsgroups: comp.arch
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 29 Sep 92 00:56:18 GMT
Organization: Silicon Graphics, Inc.

In article <7414@charon.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes:
|> In article <1992Sep26.204430.29763@odin.corp.sgi.com>
|> mash@mash.wpd.sgi.com (John R. Mashey) writes:

|>  > 2) With the sole exception of the 68000->68020 transition, I cannot
|> think
|>  > of a major computer architecture done in the last 10 years that
|>  > included indirect addressing, and none at all that permitted
|> multi-level
|>  > indirect addressing (or the PDP-10 sort).  I.e., CPU designers
|>  > have voted this feature down....  no matter how nice it may seem.
|> Perhaps not major (only at some time).  But the NS 32k:
|>         MOVW     4(8(FP)),4(12(FP))
|> done in the last 10 years.  There is even a reasonable C construct that
|> maps to this (think pointers to structures and copying one to the
|> other)!

Sorry, the verb "done" was vague.  I should have been clearer and said
what I was thinking: "in which the design was done in the last 10 years".
As I recall, 68020s started appearing late in 1984/early 1985, and were
in systems products certainly by late 1985/early 1986.
I'd guess that the design (and the decision to add those features)
must have been made in 1982 or maybe in early 1983, which is why I
included it. (somebody who knows?)

The NS16032 (which got renamed later 32016) was already shipping in
mid-1982
(from UNICOM Proceedings, January 1983: "UNIX for the National 16032"
mentions a demo of a UNIX system at November 1982 COMDEX). Backing off
that date, one would guess that the design was chosen no later than 1981,
but probably in 1990 [somebody who knows?]  hence I left it off.

-- 
-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,comp.arch.storage,alt.sys.sun
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Date: 29 Sep 92 09:52:12 GMT
Organization: Department of Computer Science, U of Copenhagen

grout@sp90.csrd.uiuc.edu (John R. Grout) writes:
ddresses later.

>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 to
>be a flag byte (to save expensive memory) as a first-implementation artifact,
>the 390 architecture is stuck almost thirty years later with a mode bit to
>distinguish between 24-bit and 31-bit addresses... the Alpha architecture
>won't be caught in _that_ trap.

A similar problem occurs in the ARM processors: in the first ARM
versions (ARM 2 and ARM3 ) the PC register also contains flags. The 2
least significant bits (that aren't used anyway, as instructions must
be 32 bit aligned) contains mode information (user, supervisor etc.)
and the upper 6 bits are arithmetic and interrupt flags. This
effectively limits addresses to 26 bits, or 64 MB. This was not a
serious limit at the time the ARM was designed (in 1986, where the most
memory you could put in a personal computer was less than 1 MB), but
today it is a low limit indeed for a 32 bit RISC processor.

As a consequence, the new ARM 6 series (including the ARM 610, used
in Apples PDA) has 26 bit modes and 32 bit modes. In the 32 bit modes
there is a special status register that contains mode information and
flags. While most instructions are unchanged, it means that saving the
PC alone will not also save flags. This means that flags are no longer
preserved automatically across subroutine calls.

	Torben Mogensen (torbenm@diku.dk)
Newsgroups: comp.arch
From: alvitar@xavax.com (Phillip Harbison)
Subject: A reminder about posting to comp.arch (last mod 06/14/90)
Reply-To: alvitar@xavax.com (Phil Harbison)
Organization: Xavax
Date: Thu, 1 Oct 1992 07:00:05 GMT
Followup-To: poster
Summary: Stop, Think, Observe, Plan
Keywords: Netiquette

This article is posted monthly in the hope that it will encourage
proper use of comp.arch.  Your cooperation will help improve the
signal to noise ratio of comp.arch, making the newsgroup more
valuable to readers.

1) Consider using mail instead of posting a followup article.  If
   your response is of limited interest to anyone other than the
   author, then please use mail instead of posting a followup.  A
   mail message goes to a small number of machines, while an
   article consumes communication and storage resources at
   thousands of sites.

2) Exhaust local sources of information before posting a question
   to comp.arch.  It makes little sense to waste the communication
   and storage resources of thousands of sites, not to mention the
   time of thousands of comp.arch readers, when the answer to your
   question may be as close as your bookshelf.  Do read the manual.

3) If you raise new topics, make sure the subject corresponds to your
   comments.  However, do not needlessly change or amend the subject
   line, as some news readers allow a user to skip an entire thread
   based on the subject line.

4) Consider limiting the distribution of your article.  Announcements
   such as user group meetings may be of interest only to a limited
   geographic area.  Check with your local news administrator to see
   what regional or local distributions are available.

5) Quoting portions of the base article is encouraged.  It helps the
   reader to understand the context of your comments, especially if
   the reader has not read the base article.  However, you should
   include only as much of the base article as is necessary to convey
   the context of your comments.  Use an editor to remove unnecessary
   portions of the base article.

6) Make sure your article is related to computer architecture.

7) Computer nostalgia has a place on the net, but that place is not
   comp.arch.  If you are discussing architectural features of past
   generations of computers, then comp.arch is appropriate.  However,
   the prescribed place for computer nostalgia is alt.folklore.computers.

8) Sale advertisements and product announcements are not appropriate
   for comp.arch.  There are specific groups for these purposes.  Try
   misc.forsale, misc.forsale.computers, and comp.newprod.  Also, keep
   in mind that news articles are distributed by various services which
   forbid use for personal gain.  Sites which use these services often
   selected newsgroups such as comp.arch assuming a high information
   content and no personal gain use.  Please do not make their life
   more difficult by posting advertisements and product announcements.

-- 
*realName: Phil Harbison
*mailAddress: Xavax, PO Box 125, Shokan, NY 12481
*eMailAddress: alvitar@xavax.com
*phoneList: <home>: 914-657-8645  <work>: 914-385-2881
Newsgroups: comp.arch
From: bt@irfu.se (Bo Thide')
Subject: Re: Which is the Best RISC Arcitecture ?
Date: Wed, 30 Sep 1992 14:48:06 GMT
Organization: Swedish Institute of Space Physics, Uppsala, Sweden

In article <1992Sep25.082119.1341@odin.diku.dk> torbenm@diku.dk (Torben AEgidius Mogensen) writes:
>mjohnson@netcom.Netcom.COM (Mark Johnson) writes:
>
>>In article <1992Sep24.180118.1392@sun1.ruf.uni-freiburg.de> wolf@sun1.ruf.uni-freiburg.de (Klaus H.Wolf) writes:
>>    > (I know SPARC, MIPS, 88k, POWER, DSP96002)
>
>
>>To those, add
>>     Clipper    (Intergraph)
>>     Precision  (Hewlett Packard)
>>     Swordfish  (National Semiconductor)
>>     i860       (Intel)
>>     i960       (Intel)
>>     ARM        (Acorn / VLSI Technology)
>>     Regulus    (Computer Consoles Inc)
>>     Lightning  (Metaflow / LSI Logic)
>>     Pinnacle   (Ross Tech / Cypress)
>>     Ice        (NEC / MIPS)
>
>
>HP precision architecture may not be available outside HP.

HP-PA is licensed to seven other companies (the so called PRO group, including
Samsung and Hitachi) and to Convex, who will use PA in their new series of
supers.

Bo
-- 
   ^   Bo Thide'--------------------------------------------------------------
  |I|        Swedish Institute of Space Physics, S-755 91 Uppsala, Sweden
  |R|      Phone: (+46) 18-303671.  Fax: (+46) 18-403100.  IP: 130.238.30.23
 /|F|\          INTERNET: bt@irfu.se      UUCP: ...!mcvax!sunic!irfu!bt  
 ~~U~~ ----------------------------------------------------------------sm5dfw-
Newsgroups: comp.arch