🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #21308

Re: Register Scoreboarding

#21308
From: Hugh LaMaster
Date: Wed, 17 May 1989 15:58
70 lines
4311 bytes
In article <104999@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - SPD Languages Marketing -- MTS) writes:

>I can't think of a supercomputer which _does_ use scoreboarding, at
>least not as I understand the term. Supercompuers tend to not have

I don't know much about the Japanese machines, but all the CDC and Cray
machines I am familiar with do register scoreboarding.  They do not do
the full "Tomasulo" scoreboarding, in that instruction issue stalls if
registers are busy.  

Note that what scoreboarding buys you is the ability to continue
issuing instructions after a memory operation without knowing how long
a particular memory access will take.  This is very important in a machine
which has 8 processors, 32 memory ports, 256 memory banks, and memory
latencies of at least 4-5 clock periods, and sometimes longer.

Some architectures permit a certain number of instruction issues to continue
if registers are busy, and this is a sort of local dataflow, as someone
mentioned previously.  I don't think any of the current crop of machines do
that, although I assume that the IBM 360/91 did since that was the machine
that Tomasulo wrote his paper about (it is reprinted in Siewiorek, Bell, and
Newell's "Computer Structures" that probably most people have).

Specifically, current machines do not seem to have "reservation stations" which
permit instruction issue to continue (on the 360/91 it was floating point
add and multiply only, I believe) if the register is busy.  Anyway, with
instruction scheduling in the compilers (for the last 15 years ...) 
the claim is that this sort of multiple outstanding instruction issue
capability buys you very little over the current technique (stall if busy).
I believe that the level of scoreboarding used plus instruction scheduling
is believed to be "locally optimal" for a pipelined machine with segmented
functional units.  Reservation stations may increase the parallelism
slightly at some cost in functional unit latency.

The main point is that if you want to have multiple outstanding loads,
indeterminate memory delays due to bank busy conditions, multiple
outstanding instructions (all or almost all the ALU operations on these
machines are fully segmented- typically at one per clock cycle, though
not always with divide etc.), and, fairly long memory latencies 
(e.g. 5-13 clock periods) scoreboarding is a nice way to handle it.

>These machines typically have interlocks; but nothing like the
>scoreboard scheme of the 88K (unless my memory is very leaky this
>week). 

The first use of the term "scoreboard" that I know of was Thornton's
1964 paper on the CDC 6600, also in Siewiorek, Bell, and Newell.

>Scoreboarding probably works; but there seems to be a certain lack of
>evidence that it is necessary. Seems overly complex to me .... but
>what do I know... I studied math and grew up working in Kalman
>filtering applications ... :>

I am not sure what is "overly complex" about it.  If you have one path to
memory on a one CPU system, it isn't necessary.  If you have multiple paths
on a multiple CPU system, it turns out to be just what you need.  If you
are concerned about increasing the critical path in instruction issue by
by one level, you are probably right, though clever hiding of these things
may occur.  Anyway, as always, the question is: Do you get what you pay for
out of it.  The fact that it has been used for 25 years on machines with
multiple paths between the CPU and memory should say something.




  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117       
Technical Details
Message-ID: <25484@ames.arc.nasa.gov>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!ames!ames.arc.nasa.gov!lamaster
References: <24821@lll-winken.LLNL.GOV> <GRUNWALD.89May9113443@flute.cs.uiuc.edu> <3288@orca.WV.TEK.COM> <19463@winchester.mips.COM> <170@dg.dg.com> <19661@winchester.mips.COM> <104999@sun.Eng.Sun.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!ames!ames.arc.nasa.gov!lamaster
From: lamaster@ames.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: Register Scoreboarding
Message-ID: <25484@ames.arc.nasa.gov>
Date: 17 May 89 15:58:59 GMT
References: <24821@lll-winken.LLNL.GOV> <GRUNWALD.89May9113443@flute.cs.uiuc.edu> <3288@orca.WV.TEK.COM> <19463@winchester.mips.COM> <170@dg.dg.com> <19661@winchester.mips.COM> <104999@sun.Eng.Sun.COM>
Sender: usenet@ames.arc.nasa.gov
Organization: NASA - Ames Research Center
Lines: 70