HDTenEightyP/NetNews huggingface dataset:
From: tuna@KANCHENJUNGA.LCS.MIT.EDU (Kirk 'UhOh' Johnson)
Newsgroups: comp.arch
Subject: Re: Multi threaded CPUs
Date: 3 Sep 92 02:18:46 GMT
Organization: Massachvsetts Institvte of Technology

stripes@pix.com (Josh Osborne) wrote:

    A little while ago I read about a RISC CPU (SPARC I think) that
    some researchers had designed. It had a cache of threads (I got
    the impression that that includes registers, and possibly MMU
    state as well), four in the current chip, and when there was a
    pipe stall the execution would just switch to another thread.

to which preston@cs.rice.edu (Preston Briggs) added:

    Anant Agarwal, at MIT, was working on a modification of the SPARC,
    called Sparcle, to be used as a node in a large-scale
    multiprocessor called Alewife. He gave a talk on the project last
    year at a workshop during Supercomputing '91. Unfortunately, I
    have only a brief abstract here.

    My memory from the talk was that they used each set of registers
    in the SPARC's register windows to support a different thread. Can
    switch threads in 11 cycles. Probably use the multithreaded
    behavior to hide communication latency.

this is essentially correct. in SPARCLE, we use the SPARC register
windows to keep the state (registers) for multiple contexts (four, in
this implementation) in hardware so we can rapidly switch between
them (14 cycles). SPARCLE will be used as the integer unit in Alewife;
as preston suggests, the multithreading feature is used as a
communication (and synchronization) latency hiding mechanism. note
that SPARCLE only switches contexts on cache misses and explicit
program directives; random pipe stalls for other reasons do not cause
context switches. also note that the SPARCLE contexts do not include
MMU state.

we've had working SPARCLE silicon (40 MHz) for almost six months now;
we're furiously hacking to get the rest of the Alewife hardware ready
to go.

anant did give a SPARCLE talk at hot chips, but alas there was no
associated paper. there was an early SPARCLE paper in ISCA'90, though: 

 @InProceedings(Agarwal-april,
  Author    = "Anant Agarwal and Beng-Hong Lim and David A. Kranz and
               John Kubiatowicz",
  Title     = "{APRIL: A Processor Architecture for Multiprocessing}",
  BookTitle = "Proceedings 17th Annual International Symposium on
               Computer Architecture",
  Pages     = "104-114",
  Month     = "June",
  Year      = "1990")

we are also hoping to have another SPARCLE paper (with quite a bit
more detail) out RSN.

there were a couple of papers that appeared as posters in the most
recent ISCA ('92) which talked about issues related to multithreaded
processors -- one from jim laudon (stanford), one from dave culler
(berkeley); both of these made interesting reading. if anybody is
interested and can't get the info themselves, i can probably chase up
better references, e-mail addresses, or postscript for these.

share and enjoy,

kirk
-- 

 Kirk Johnson ------ tuna@lcs.mit.edu ------ Yow! Have I graduated yet?
Newsgroups: comp.arch
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: Program behaviour (was Re: trapping speculative ops
Date: 29 Aug 92 23:37:00 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

bbs.dennis@tsoft.sf-bay.org (Dennis Yelle) writes:
>schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:
>> Some people (including me), believe that there is only *one* level
>> of optimization. One should always ship the same binary that one
>> tested; 

>I agree.  This is why I am annoyed that most linkers put the
>debug information in the executable file.  I think that the
>debug information should be put in a different file (ending with .dbg
>perhaps).  Then I could test, debug, and ship EXACTLY the same binary.

	However, adding some types of debug information can modify the 
generated code, so you have to be careful about it (know your linker/
compiler/debugger and it's habits).  Good linkers have the ability to
strip debug information out of an executable for shipping, without modifying
the code you debugged.

-- 
"Rev on the redline, you're on your own; seems like a lifetime, but soon it's
 gone..."  Foreigner
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
From: moss@cs.umass.edu (Eliot Moss)
Newsgroups: comp.arch
Subject: Re: Multi threaded CPUs
Date: 3 Sep 92 02:22:56 GMT
Reply-To: moss@cs.umass.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
In-reply-to: stripes@pix.com's message of 2 Sep 92 01:57:35 GMT

For an aggresive multithreading, take a look at the Tera machine. It was
described in Supercomputing '90 as I recall.
--

		J. Eliot B. Moss, Associate Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: trapping speculative ops
Organization: Intel Corp., Hillsboro, Oregon
	<1992Aug27.005340.6547@bcars64a.bnr.ca>
Date: Sat, 29 Aug 1992 01:40:35 GMT

>In article <CLIFFC.92Aug26084159@medea.rice.edu> cliffc@rice.edu (Cliff Click) writes:
>>Let every register have some extra "trap" bits.
>>A read of the register with it's trap bits set, causes the exception.
>>A write to the register sets the trap bits according to the success of
>>the operation.
>>
>>With this design, exceptions are triggered at the START of some operation,
>>instead of in the middle of it.
>
>[schow@bqneh3.bnr.ca (Stanley T.H. Chow)]
>Very nice model, but what to do about saving and restoring registers
>across subroutine call, interupts, etc.?

(1) It would be trivial for a compiler to arrange that all potential
faults have been verified before a procedure call => no need to save
the trap bits.  Similarly, it would probably be not very necessary for
a compiler to spill registers that contain potential faults.

(2) If you have 64 registers, a single register can hold the trap bits
for them all. I wouldn't feel too bad about adding that to the state
to be saved/restored on an interrupt or context switch.

(3) There are techniques that have been discussed for making the trap
bits "hidden", not user visible.  Myself, I think that goes against
the RISC philosophy.

(4) Adding "extra" bits to a register makes some other common
operations, that do not fit into a standard 2input 1output format,
much easier to do.

--

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)
Newsgroups: comp.arch
From: zs@munta.cs.mu.OZ.AU (Zoltan Somogyi)
Subject: Re: Multi threaded CPUs
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 2 Sep 1992 08:59:06 GMT

stripes@pix.com (Josh Osborne) writes:
>A little while ago I read about a RISC CPU (SPARC I think) that some
>researchers had designed.  It had a cache of threads (I got the impresion
>that that includes registers, and posabble MMU state as well), four in
>the current chip, and when there was a pipe stall the execution would just
>switch to another thread.

The paper you are looking for is in the proceedings of the 1990 International
Symposium on Computer Architecture, on page 104. It is by Agarwal, Lim, Kranz
and Kubiatowicz, and its title is "APRIL: a processor architecture for
multiprocessing". It describes the MIT Alewaife machine.

Zoltan Somogyi <zs@cs.mu.OZ.AU>
Department of Computer Science, University of Melbourne, AUSTRALIA
Newsgroups: comp.arch
From: stripes@pix.com (Josh Osborne)
Subject: Re: Indexing in microprocessors
Organization: Pix Technologies -- The company with no adult supervision
Date: Wed, 2 Sep 1992 01:45:22 GMT

In article <1811llINN3ci@usenet.INS.CWRU.Edu> ugurdag@ces.cwru.edu (Fatih Ugurdag) writes:
>Is there any microprocessor in which we can access registers in an
>indexed fashion such as      [...]

The AMD290xx's sort of do.  I may get the exact reg numbers wrong, but
the idea is the same.  A group of registers, 64 or 128 (I forget which)
are rolled by the value in G1.  If G1 is 0 then an add to G64 will add
to register 64, if G1 is 10 then the same add would effect G74.  It is
normally used a lot like register windows (i.e. you pass arguments in
them rather then the stack), however AMD can't transparently change the
number of register windows to improve performance, nor do you need to use
(say) 16 registers for a function call when 3 will do.
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
From: bbs.dennis@tsoft.sf-bay.org (Dennis Yelle)
Newsgroups: comp.arch
Subject: Re: Program behaviour (was Re: trapping speculative ops
Date: 28 Aug 92 19:19:07 GMT
Organization: The TSoft BBS and Public Access Unix, +1 415 969 8238

schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:

> Some people (including me), believe that there is only *one* level
> of optimization. One should always ship the same binary that one
> tested; doing otherwise expresses immense faith in the ability of
> one's process to recompile the same source as well as the correctness
> of ones tools - the compilers, optimizes, linkers.
> 

I agree.  This is why I am annoyed that most linkers put the
debug information in the executable file.  I think that the
debug information should be put in a different file (ending with .dbg
perhaps).  Then I could test, debug, and ship EXACTLY the same binary.

--
Dennis Yelle (bbs.dennis@tsoft.sf-bay.org)
From: rro@cs.ColoState.EDU (Rod Oldehoeft)
Newsgroups: comp.arch
Subject: Re: Multi threaded CPUs
Date: 2 Sep 92 14:19:09 GMT
Reply-To: rro@cs.ColoState.EDU
Organization: Colorado State University

Apropos this subject, there will be a minisymposium on Multithreaded
Computer Systems at the Supercomputing Conference this November in
Minneapolis.  Greg Papadopoulos, MIT,  will cover architecture, Wim
Bohm, Colorado State, will discuss software, and Tony Dahbura,
Motorola, will give an industrial perspective.

-- 
|--------------------------------------------------------------|
| Rod Oldehoeft                    Email: rro@cs.colostate.edu |
| Computer Science Department      Voice: 303/491-5792         |
| Colorado State University        Fax:   303/491-6639         |
| Fort Collins, CO  80523                                      |
|--------------------------------------------------------------|
| Three outstanding attitudes---obliviousness to the growing   |
| disaffection of constituents, primacy of self-aggrandizement,|
| and the illusion of invulnerable status---are persistent     |
| aspects of folly.   ---Barbara Tuchman, "The March of Folly" |
|--------------------------------------------------------------|
From: lu@topcad.ucsd.edu (George Lu)
Newsgroups: comp.arch
Subject: digital noise in CPUs
Keywords: noise CPU 486 SPARC
Date: 26 Aug 92 00:26:14 GMT


Hi guys,

I need to get some information on the digital noise levels on the
power and ground pins of busy processors like the 486 or SPARC chips.
Does anybody have typical values for something like that?  Also does
anybody know if the 486 has on chip de-coupling capacitors?  If yes,
what is a typical value?  Post here or email to my at lu@ece.ucsd.edu.
Thanks in advance.

George Lu
UCSD ECE Dept.
George Lu						UCSD ECE dept 0407
lu@ece.ucsd.edu						La Jolla, CA 92093
UCSD Optical Information Processing Group		(619)534-1743
Newsgroups: comp.arch,sci.math,comp.lang.misc,comp.lang.fortran,comp.edu
From: awolfe@oink.Princeton.EDU (Andrew Wolfe)
Subject: Re: ALPHA : Single Transistor Clocking
Originator: news@nimaster
Organization: Princeton University
Date: Thu, 3 Sep 1992 13:18:38 GMT

My understanding of the Alpha 21064 chip (from several presentations) is that it uses a single inverter for clock distribution.  This is built from one large PMOS and one large NMOS device.  They have a total gate width of over 14 inches.

The AWESIM timing simulator from CMU was used to model this circuit.  Obviously, since the chip is not 14" long, the devices are folded quite a number of times.
-- 
--------------------------------------
Andrew Wolfe
Assistant Professor
Department of Electrical Engineering
Princeton University
From: yvent@ntua.gr (Yiannis Ventikos)
Newsgroups: comp.arch
Subject: MARKET SURVEY FOR MASS. PARALLEL MACHINES
Summary: We are checking the market for a massiv. parallel machine.
Keywords: MASS PARALLEL
Date: 2 Sep 92 07:28:43 GMT
Organization: National Technical University of Athens



            MARKET SURVEY FOR MASS. PARALLEL MACHINES

We are checking the market for a massiv. parallel machine. We got no specs so
far, just price ranges:

Class a) Up to two  million US dollars ($2 000 000)
Class b) Up to four million US dollars ($4 000 000)
Class c) Up to six  million US dollars ($6 000 000)

Since this is an initial survey, we do not want to exclude anything, so the
definition "massiv. parallel machine" is to be taken in the broadest sence.
Any input is wellcomed, ranging from simple info like :
"XYZ  costs $2.3M"
to
"ABC with n processors, M Mbytes, G Gigaflops..."
up to 
"We have purchased a FGH and have been using it for... Our experience..."

Any and all answers will be appreciated. 
E-mail at the address at the end of this message is better, if too 
difficult just followup.
-------

******************************************************************************
* Yiannis Ventikos                              *        DISCLAIMER          *
* Viscous Flows Group,                          * Any and all opinions that  *
* Dept. of Naval Arch. & Marine Eng.,           * I have  expressed  so far  *
* National Technical University of Athens,      * reflect  thoughts of mine  *
* P.O. Box 64070, GR-15710, Zografos, GREECE    * and  mine alone and  have  *
* Voice: (301) 7700405                          * nothing  to do  with  the  *
* Fax:   (301) 7774478                          * policy of the  Department  *
* e-mail: yvent@areti.marinentua.ariadne-t.gr   * I currently belong to.     *
******************************************************************************
From: hepler@cbmvax.commodore.com (Ed Hepler - LSI Design)
Newsgroups: comp.arch
Subject: CD-ROM Error detection and correction
Date: 4 Sep 92 13:51:50 GMT
Organization: Commodore, West Chester, PA

Does anyone know the generator polynomial, g(x), used to encode the P and Q
error detection and correction codewords for CD-ROM?  The YELLOW book 
specifies P(X), as x**8 + x**4 + x**3 + x**2 + 1, but this only defines
the primitive polynomial for GF(8).  I am looking for the polynomial used
to actually generate the codewords (and therefore used for decoding).

Thanks,

Ed Hepler
Commodore
hepler@cbmvax.cbm.com
From: glew@pdx007.intel.com (Andy Glew)
Subject: Computer Architecture Rationale
Organization: Intel Corp., Hillsboro, Oregon
Date: Sat, 29 Aug 1992 01:11:14 GMT


pcg> Well, this brings us to a more general sort of argument about
pcg> architecture, and that is the design rationale issue. It is very
pcg> rare that an architecture description is accompanied by its design
pcg> rationale, by the guiding principles behind it. ...

Well, if it's anything, the architecture descriptions I have been
working on always have a "rationale" section in them.

Except that it is usually conditional text, not given to customers,
and even removed from the copy I give my managers. I keep it around
for the architects who have to maintain the architecture - add new
features, etc.

I once made the mistake of giving my manager a copy of the
architecture description with the rationale visible as struck out
text, clearly indicated as such. The rationale described some of the
rejected alternatives, and the reasoning --- but it also clearly
stated what was planned, in the form of a specification. Status report
said "Architecture description more a collection of alternatives than
a plan".  Right away I gave him a copy of the same spec, with the
rationale conditional text turned off (invisible). Next status report
said "Architecture description much improved."

Moral: no matter how clearly you try to separate rationale from
decision, some people will get confused.
--

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: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.arch
Subject: Re: Computer Architecture Rationale
Date: 29 Aug 92 05:28:59 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


However it would be a service to students of computer architecture to get
the rationale in public print, even if it has to wait until the end of
the product life cycle.  One of my favorite books is the one edited by
Werner Buchholz on Project Stretch, in which the designers documented the
alternatives they considered and the reasons for their decisions.
I suppose they could do this because Stretch wasn't going anywhere as a
product.  Sure wish I had such a book about the IBM 360 architecture.
There is a book about IBMs 360 and early 370 computers; but it's mostly
about the trials and tribulations of getting the thing designed and
produced and not enough about how architectural details were decided.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle
From: Nick_Janow@mindlink.bc.ca (Nick Janow)
Newsgroups: comp.arch
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted
Date: 2 Sep 92 05:49:32 GMT
Organization: MIND LINK! - British Columbia, Canada
Distribution: world

ashok@regulus.Inria.Fr (Ashok Kumar) writes:

> I fully agree with you.To draw an analogy from Mech engg. a good mechanical
> engineer need not necessarily be a good machinist.He can design a good
> product and leave the implementation on a lathe or a milling machine or what
> have you to a skilled machinist.Similarly a good architect or civil engineer
> need not be good mason.

Unfortunately, the Mech Eng who doesn't understand what the reality of
machining his "great design" involves, may have a product that is only good on
paper (or simulation file).  The beautiful stone columns the idealistic
architect used on paper might need expensive hidden reinforcement when actually
built.

There are valid reasons for why companies are interested in concurrent
engineering: designers who don't understand the manufacturing and marketing
aspects of a product waste a lot of money making the necessary changes to make
their idealistic designs meet reality.

I assume the situation is the same for software.

--

Nick_Janow@mindlink.bc.ca
Newsgroups: comp.arch
From: bob@tera.com (Bob Alverson)
Subject: Re: trapping speculative ops (LONG)
Reply-To: bob@tera.com
Organization: Tera Computer Company, Seattle, WA
Date: Tue, 1 Sep 1992 15:20:44 GMT

To quote William Kahan:

	Exceptions are not errors.
	Exceptions are not errors.
	Exceptions are not errors.
	Exceptions are not errors.
	Exceptions are not errors.
	Exceptions are not errors.
	Exceptions are not errors.
	Exceptions are not errors.
	Exceptions are not errors.
	Exceptions are not errors.

	Unless they are handled badly.

In other words, if you think you can roll over and die when you take an exception,
you are severely restricting hardware and software.  In many cases, some fix up
is desired followed by a return from the exception.  Continuing in this way can
be quite challenging if you have gone too far forward.  Values that were around
may no longer be anywhere to be found.  However, an architectural way to guarantee
that no traps from an operation will occur in the future is nice.  DEC's Alpha
has the sledge-hammer-like trap barrier.  Being able to selectively touch off
traps gives the compiler more control and may allow better pipeline usage.

Bob
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: comp.arch
Subject: Re: ALPHA : Single Transistor Clocking
Summary: Five stages used, many xtors
Keywords: Alpha, clocking
Date: 4 Sep 92 03:54:18 GMT
Organization: Digital Equipment Corporation


In article <1992Sep3.004732.15291@rkna50.riken.go.jp>, wong@rkna50.riken.go.jp (Wong Weng Fai) writes...
> [deletions]
>According to what I know, right dead center of the ALPHA chip is a single,
>huge transistor that is used for clock distribution. Can anyone provide
>further details on this ? What are the advantages and disadvantages ? Is it
>the way to go for distribution of high frequency clocks ?

As Mark Johnson previously noted, the clock driver is fully described in the
ISSCC Digest of Papers, 1992, and the accompanying slide set.  The clock
driver is a multistage driver, with devices scaling up to the final inverter.
This final inverter uses wide devices, 25cm and 10cm for P and N channel,
respectively.

The design of the Alpha clock driver was motivated by the need to achieve
under 300ps corner to corner skew under worst case operating and process
conditions.  To do this, every clock node in the chip is driven directly
from the clock driver, without intermediate rebuffering.  The size of the
clock driver (and its final inverter) falls out from the amount of
capacitance which must be driven every cycle.

Other designs -- such as locally rebuffered clocks, or locally generated
clocks phase-locked to a master reference -- are certainly possible.  This
one works (at 200Mhz), and the design team was able to prove, early in the
design process, that it would work, thereby eliminating a lot of risk
from the design.  (The ISSCC slides include a simulation of the propagation
of the clock wave form, at 30ps intervals, out from the center, on the
extracted clocking network of the chip -- more than 600k nodes and arcs.)

Bob Supnik	>Supnik@human.enet.dec.com
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation
Newsgroups: comp.arch
From: XB.UVC@forsythe.stanford.edu (Judith Lemon)
Subject: Computer Architecture Videos
Organization: Stanford University, California, USA
Date: Wed, 2 Sep 1992 01:21:14 GMT


University Video Communications would like to know
if the comp.arch community wants us to post
information about our computer architecture videotapes.

University Video Communications produces tapes
by major architects on RISC, large scale parallelism,
multiprocessors, and supercomputers and makes them
available at modest cost.

Abstracts and ordering information available on request.


Dr. J.L. Lemon
President
uvc.lemon@forsythe.stanford.edu
Newsgroups: comp.arch