HDTenEightyP/NetNews huggingface dataset:
From: jkenton@world.std.com (Jeff Kenton)
Subject: Re: What was the intended advantage of using 36bits CPU?
Organization: Kenton Systems Corporation, Weston MA
Date: Mon, 5 Oct 1992 14:08:19 GMT

In article <ld0gv1INNfh9@news.bbn.com> fwebb@star-trek.bbn.com (Fred Webb) writes:
>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.
>

In addition, IBM machines before the 360 also had 36 bit words.


[Hi Fred]


-- 
-------------------------------------------------------------------------
=			Jeff Kenton	(617) 894-4508			=
=			    jkenton@world.std.com			=
-------------------------------------------------------------------------
Newsgroups: comp.arch
From: jcarroll@ferris.cray.com (Jeff Carroll)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Originator: jcarroll@ferris
Organization: Cray Research, Inc.
Date: 2 Oct 92 22:28:27 CDT


In article <Bv8tzG.Kv1.2@cs.cmu.edu>, lindsay+@cs.cmu.edu (Donald Lindsay) writes:
> 
> In article <14813@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
> >There's an interview with Roger Ross ...
> >	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.
> 
> I count four:
> - Alpha  (which is about to be named VRX or some such??)
> - R4000
> - Ncube-2 node processor, I think

Unless they've come out with some new piece of silicon for the Ncube 2
(in which case they should call it something else, IMHO), it's a 32-bit
machine.

Also I thought that the R4000 wasn't capable of driving the entire 64 bits
of address space, or something...

Jeff Carroll
carroll@herndon.cray.com
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: implementing random replacement
Date: 27 Sep 92 01:20:42 GMT
Organization: School of Computer Science, Carnegie Mellon

In article <MOSS.92Sep22225716@CRAFTY.cs.umass.edu> moss@cs.umass.edu writes:
>Another cheap and easy
>possibility is a feedback shift register that generates a pseudorandom
>sequence. Don't know what folks have actually implemented, though ....

There are pseudorandom generators in the Fat Tree of the CM-5.

CM-5 messages rise towards the roots of the tree, then turn and use
their destination address to determine their path back down the tree.

However, the ascent phase is *not* deterministic.  At each node, a
message may have multiple uplinks available (which would take it
towards different roots: it's a multirooted tree).  Each message
chooses randomly among the nonbusy uplinks.

I asked why a counter's pseudorandomness wasn't good enough. The
answer was that the extra randomness broke up traffic patterns and
made congestion that much less likely.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Newsgroups: comp.arch
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: Multiplication on your favorite CPU (summary)
Date: Wed, 30 Sep 1992 13:58:02 GMT
Organization: University of Iowa, Iowa City, IA, USA

From article <martin.717857097@bert>, by martin@math.rwth-aachen.de (  Martin Schoenert):
> 
> Motorola 680[01]0:
> 
>   32x32 -> 64:      no
>   32x32 -> 32:      MULU.W

	As someone who's tried to implement multiplicative congruential
	random number generators on the M68000 and M68010, I found out
	the hard way that the MULU.W command is 16x16 -> 32 -- that is,
	even though the operands are all 32 bit registers, only the least
	significant 16 bits of the operands are used.  This is very
	disturbing, particularly because many of the compilers on the 68020
	and up still refuse to use the long multiply.

				Doug Jones
				jones@cs.uiowa.edu
Newsgroups: comp.arch,comp.lang.misc
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: PDP-10 registers and cache
Organization: Curtin University of Technology
Date: Wed, 30 Sep 1992 16:06:32 GMT

In article <ADAMS.92Sep25172127@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>, adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams) writes:
> In article <1661@idacrd.UUCP> desj@ccr-p.ida.org (David desJardins) writes:
> 
> Why should I, Joe User, care about physical implementation of register
> sets?  Might I remind, that some architectures like PDP10 (KA10 or KL
> 10 ??) used in fact multiported cache as register file, which was
> mapped into lowest addresses of user space ...
> 

Uh hum, The KA didn't have a cache, but did have a 16x36 bit of flip-flops in
the ALU that responded to the first 16 ( 0-17 ) addresses. These where call
" the ACs ", " Fast memory " or " the registers ".Seems to depend on how old
you are. :-)

The KL has 8x16x36 bits of registers on the M8512 board. The Cache is several
seperate boards in the M-box, about 8" away from the ALU. The cache is notably
single ported, and burried in 69 feet of crap logic, until you remember what
the cycle time of core memory was like...

> ( Each context had 0400 [256] words of cache assigned, during context
> switch, chache regions were swapped, invalidated and written back on
> demand to memory...., simple, efficient and fast)
> 

The cache allocation and mapping policy is loaded at init time, and can be, and
was, altered to taste. The logic in the KL-10[D,E,RE] goes to HUGE lengths by
recently past standards *, to avoid writing to core, and to maximize the pay-
off of any read. The standard u-code loaded allocated 1/2 the cache to USER
and 1/2 to EXEC. This is noted as being optimized for 'small user' ( <40000K )
situations on TOPS-10. I don't know what cache policy ITS or WAITS used.

* The reason I worded it this way, is that I can see system designers reaching
for a lot of the 'cruft' that the older machines used, for the same sort of
reason; primary memory speed is now LOTS less than CPU speeds, hence waiting
for Mp is a very costly event.

~Paul

Newsgroups: comp.arch
From: alan@utrc.utc.com (Alan Finn)
Subject: Re: implementing random replacement
Summary:  The i860 has random replacement, too
News-Software: VAX/VMS VNEWS 1.41    
Keywords:  cache, replacement
Organization: United Technologies Research Center
Date: Fri, 25 Sep 1992 20:26:00 GMT

In article <1992Sep23.083717.20050@inmos.co.uk>, roger@gimli.inmos.co.uk 
(Roger Shepherd) writes...
>The T9000 transputer [...] cache a random replacement policy is used [...]

The i860 also uses random replacement, see

M.W. Rohdehamel, 'The Bus Interface and Paging Units for the i860tm
Microprocessor', Proc. 1989 ICCD, Cambridge, MA, Oct. 2-4, 1989, pp.380-384.

On page 382 Rohdehamel states "A simple, two bit counter was investigated
[...] but was rejected due to the increased probability of cache thrashing"
and "The LFSR pseudo-random generator, which is approximately twice the
of the two bit counter in silicon and logic complexity, was chosen"

-------------------------------------------------------------------------------
Alan Finn                                    | 
E-Mail Alan@UTRC.UTC.COM                     | If the only tool you have is 
V-Mail (203) 727-7737                        | a hammer, then every problem
S-Mail United Technologies Research Center   | looks like a nail.
       411 Silver Lane                       |                     -anon.
       East Hartford, CT 06108               |
-------------------------------------------------------------------------------
Newsgroups: comp.arch,comp.lang.misc
From: gbyrd@ncsc.org (Gregory T. Byrd)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Reply-To: gbyrd@ncsc.org (Gregory T. Byrd)
Organization: North Carolina Supercomputing Center
Date: Mon, 28 Sep 1992 13:14:09 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)

[rest deleted]

Don't know why you made this caveat with the KSR1 processor and
not the others.  Alpha only implements a 43-bit address, and
the R4000 implements a 40-bit address, I believe.  I don't know
about plans for the nCUBE-2 processor.

The KSR1 certainly has 64-bit integers and floats.

...Greg Byrd             North Carolina Supercomputing Center
   gbyrd@ncsc.org        P.O. Box 12889
   (919)248-1439         Research Triangle Park, NC  27709-2889
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: Tue, 29 Sep 92 08:48:15 GMT

In article <1665@idacrd.UUCP> desj@ccr-p.ida.org (David desJardins) writes:
>Every store (with very rare exceptions) sooner or later is going to cost
>you memory cycles.  

My remark was in the context of using intermediate memory locations when
doing spills between floating point and integer registers, or general
register save/restore. These things tend to be in a smallish area
of memory that usually is cached (if it weren't, a writeback cache
would also fail).

>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.

Which isn't rare at all when you use it for spills or are frantically
jumping up and down one level of procedure call stack (with register
save and restore) in a loop. The 21064 write buffer can hold 4 full
cache lines (i.e 128 bytes), so capacity usually isn't an issue either.

>  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.

The same will happen here. The 21064 treats it's write buffer very much
like a write-back cache. As long as only a single entry is "active", it
will not bother writing it out (for 256 cycles), when a second (or more
blocks) enter, it will start writing them, merging writes into all
blocks (except the "head entry", which is being written out), but the
bus interface unit does this at lowest priority, hence as long as your
not totally buried under first level cache misses it will do this 
in it's spare time.

>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?

Almost. Usually the next level out is not memory but second level
cache, making the sequence of operations you describe correct, but
give much less performance impact. 

		Burkhard Neidecker-Lutz

Multimedia Engineering, CEC Karlsruhe	   EERP Portfolio Manager
Software Motion Pictures		   Multimedia Base Technology
Digital Equipment Corporation
neidecker@nestvx.enet.dec.com
From: mac@coos.dartmouth.edu (Milton A. Colvin)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 6 Oct 92 00:06:52 GMT
Organization: Dartmouth College, Hanover, NH

>I was wondering what was the advantage of having 36 bits instead of 32
>or other 8*n (n>4) architecture.

So a word can hold 5  7-bit ASCII characters with a bit left over for the
garbage collector.

Everything was once a multiple of 6 - 60 bits, 36 bits, 12 bits, 24 bits.
Except for the DDP-19 which had 19-bit words.
Newsgroups: comp.arch
From: lfm@pgroup.com (Larry Meadows)
Subject: Re: implementing random replacement
Date: Sat, 26 Sep 1992 15:38:53 GMT
Organization: The Portland Group, Portland, OR
Keywords: cache, replacement

In article <25SEP199215265706@utrcv1> alan@utrc.utc.com (Alan Finn) writes:
>
>The i860 also uses random replacement, see
>
Can any one tell me why true LRU wasn't/isn't used?  Is it too expensive?
Are there performance reasons why random is better?  The random replacement
on the i860 is a real pain for vector code.
-- 
Larry Meadows		The Portland Group
lfm@pgroup.com
Newsgroups: comp.arch
From: dpa@csl36h.csl.ncsu.edu (Dr. Dharma Agrawal)
Subject: Call for papers
Reply-To: dpa@csl36h.csl.ncsu.edu (Dr. Dharma Agrawal)
Organization: North Carolina State University
Date: Fri, 2 Oct 1992 16:08:19 GMT

\documentstyle[12pt] {article}
\input{./psfig.tex}
\pagestyle{empty}
\setlength{\textheight}{8.75in}
\setlength{\columnsep}{2.0pc}
\setlength{\textwidth}{6.8in}
\setlength{\topmargin}{0.25in}
\setlength{\oddsidemargin}{-.19in}
\begin{document}
\begin{center}
{\large \bf Call for Papers}\\
\vspace{.25in}
Special Issue of the\\
{\it Journal of Parallel and Distributed Computing}\\
{on}\\
{\bf Performance of Supercomputers}\\
\end{center}
\vspace{0.25in}

Papers are solicited for a special issue of the {\it Journal of Parallel
and Distributed Computing (JPDC)} on Performance of Supercomputers,
 to be published in October 1993.
\vspace{0.25in}

This issue will publish ten (10) regular papers (about 30 double-spaced
manuscript pages) and four (4) research notes (about 15 double-spaced
manuscript pages). Topics of interest include, but are not limited to
$\colon$
\begin{itemize}
\item Architectural Characteristics
\item Performance Evaluation Techniques
\item Applications
\item Algorithms
\item Benchmarks
\item Parallelization Techniques
\item Programming Language Issues
\item Scalability Issues
\end{itemize}
\vspace{0.25in}

Authors should follow the {\it (JPDC)} manuscript format described in the
``Information for Authors" at the end of each issue of the journal. Submit
five copies of a complete double-spaced manuscript to any of the co-guest editors.
Submissions must be received by no later than October 1, 1992 (extended
till Oct. 8, 1992). Authors will be
notified of the final publication decision by March 1, 1993.
\vspace{0.01in}
\begin{center}
{\it Co-Guest Editors}
%\end{center}
%\vspace{0.25in}
\begin{tabbing}
--------------------------------------------------------------------\=----\= \kill
%\begin{center}
{\it Prof. Dharma P. Agrawal} \> {\it Prof. Lalit M. Patnaik}\\
Box. 7911 \> Dept. of Computer Science and Automation\\
Dept. Of Electrical and Computer Engg. \> and Supercomputing Education and
Research\\
N. C. State University \> Indian Institute of Science\\
Raleigh, NC-27695-7911, USA \> Bangalore - 560012, India\\
Ph $\colon$ (919)-515-3984 \> Ph $\colon$ 91-812-342451\\
Fax $\colon$ (919)-515-7382 \> Fax $\colon$ 91-812-341683\\
E-mail $\colon$ dpa@csl36h.csl.ncsu.edu \> E-mail $\colon$
lalit@micro.iisc.ernet.in\\
\end{tabbing}
\end{center}
\end{document}


Newsgroups: comp.arch
From: barr@rome (John R. Barr)
Subject: Hobbit Technical Information?
Reply-To: barr@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Tue, 29 Sep 92 16:08:44 GMT

EE Times article today indicated that AT&T would announce details of the Hobbit  
chip on October 12th.  Can anybody tell me who I should contact to get a copy  
of their manuals?

John Barr
From: jtien@venice.eng.uci.edu (Joe Tien)
Subject: Re: implementing random replacement
Newsgroups: comp.arch
Reply-To: jtien@venice.eng.uci.edu (Joe Tien)
Organization: University of California, Irvine
Date: 30 Sep 92 00:39:50 GMT

In article <BvCpp2.EFt@metaflow.com>, rschnapp@metaflow.com (Russ Schnapp) writes:
|> 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.
|> 

But isn't a simple counter more conducive to thrashing? Adding the fencing
register may help, but I assume that needs to be determined by the compiler, and
will not really be of any use preventing the thrashing caused by the counter
approach, though I can see it being real good for loops and stuff.

Also, what is the cost of the fence register in terms of real estate? 

Joe Tien


|> |> 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,comp.lang.misc
From: root@sean.tomsk.su (Alex Povzner)
Subject: HELP: What does ARJ(or other) do besides Huffman Encoding ?
Reply-To: root@sean.tomsk.su
Organization: Elecard ltd hq
Date: Mon, 28 Sep 92 02:26:15 +0800


        What does ARJ (or any other archive program) do in order to
achive archivating the source volume into a half of it ? I.e. what does
it do besides Huffman Encoding ? I've tried a pure Huffman Encoding
and I've never got more than 1.5 compression ratio. Does anybody know : why ?


                                                Alex Povzner
----------------------
root@sean.tomsk.su
Tomsk,Siberia,Russia (Moscow,balalaika,etc)


Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: H&P's "Computer Architecture: A Quantitative Approach"
Organization: Xenix Support, FICC
Date: Fri, 25 Sep 1992 13:47:17 GMT

In article <19qin7INN199@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
> In designing a computer architecture, one could argue that it would be good
> to try to work for a smaller variance of runtimes across programs
> (translate to mean, "Satisfy people like H Rubin who have very specialized
> needs for which present architectures are horrible") at a slight
> cost of expected runtime.

For cases where the market is large enough, you get that. But not usually on
the same chip. For example, RISC processors are a pain for tight real-time
work (signal processing, for example), which is why you have things like DSPs.
-- 
Peter da Silva                                               `-_-'
Ferranti Intl. Ctls. Corp.                                    'U` 
Sugar Land, TX  77487-5012
+1 713 274 5180                                   Har du kramat din varg idag?
Newsgroups: comp.arch
From: symin@cosmos.kaist.ac.kr (Min, Sang Lyul)
Subject: Average number of instructions between context switches
Organization: KAIST
Date: Thu, 1 Oct 92 11:26:56 GMT

I am wondering what is a reasonable average for the number of instructions
between  two successive context switches. I am doing a cache simulation
for various benchmarks and the above number is needed to decide how often
we have to do cache flushing during our simulation. Any help or any pointer to
relevant literature would be greatly appreciated. Thanks.

-----------------------------
Sang Lyul Min
Dept. of Computer Engineering
Seoul National University

symin@krsnucc1.bitnet
symin@dandelion.snu.ac.kr
From: mash@mash.wpd.sgi.com (John R. Mashey)
Newsgroups: comp.arch
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Date: 29 Sep 92 18:51:57 GMT
Organization: Silicon Graphics, Inc.

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?
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....

Since there may not be anything *after* microprocessors, maybe we'll
have learned from our previous sins.  Certainly, both R4000 and Alpha
do teh same thing in checking the high-order bits of the address and
not letting somebody use them for flags.

* There is a program of mine, written in S/370 BAL, still running
today in various places.  I *guarantee* that it is using 24-bit
compatibility mode; those 8 bits of flags at the top of each pointer
were just too useful to waste :-)

	
-- 
-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
From: jtien@balboa.eng.uci.edu (Joe Tien)
Subject: Re: Best Grad Schools for Computer Engineering?
Newsgroups: comp.arch
Reply-To: jtien@balboa.eng.uci.edu (Joe Tien)
Organization: University of California, Irvine
Date: 28 Sep 92 23:40:02 GMT

In article <9209282021.AA08405@ucbvax.Berkeley.EDU>, gscott@VNET.IBM.COM writes:
|> Since the Gourman Report is late as usual.  What are people's opinions
|> on the best graduate schools for computer engineering (hardware)?
|> This would include academic as well as research aspects.  What universities
|> are doing the best research in areas such as:
|> 
|> Parallel Computing/Multiprocessing?
|> Fault Tolerance?
|> Optical Computing?
|> uP Architrecture?
|> Networking?
|> 
|> Feel free to add to the list.
|> 
|> I'm interested in hearing from people in both Academia and "The Real World".
|> 
|> Thanks,
|> 
|> George Scott
|> gms2@po.cwru.edu
|> gscott@vnet.ibm.com
|> 


How does one get a copy of that Gourman Report?

Joe Tien