🚀 go-pugleaf

In article <JAN.92Oct30175815@pallas.neuroinformatik.ruhr-uni-bochum.de>, jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:
 Work an example
|>    like DAXPY.  

|> Now let's look at the transputer. Here, all elementary instructions are one
...
|> The basic block of the loop (computing one vector element) requires 4 fp ops
|> (duplicate scalar, load and mul, load and add, store) and six integer ops for
|> address calculations, for a total of 10 ops and 14 bytes. At the beginning
.....
|> Well, the T9000, running at 50MHz, can theoretically do 4bytes/cycle
|> (limited by bandwidth to the instruction fetcher) or bursts of 8 ops
|> per cycle with all functional units going at full speed. Whether Inmos
|> can crank the speed up to 200MHz (or whether they even want to, given that
|> they want to keep the balance between computation and the speed of the
|> communications links), is anybody's guess...

Let's try again.  The code above makes perfect sense for CPUs that have NONE
of the following:
	a) Aggressive pipelining/overlapped instructions
	b) Nonzero load latencies that can be covered by other instructions
	c) Multiple and/or pipelined arithmetic units.
As described above, the loop looks like:
	loop setup
start:	{dup, load/mul, load/add, store) #1
	....
	{dup, load/mul, load/add, store) #8
	loop control, back to start:

This is simply NOT what modern aggressive chip/compiler systems want to do
at all, and it's a perfect illustration of why stack systems may have fallen out
of favor as primary processors in most general-purpose systems [regardless of
their merits or not elsewhere].  Although the code might vary a lot
according to machine, it is quite typical to generate code that
interleaves instructions to hide latencies and take advantage of multiple
functional units, i.e., they'd look like:
	LOAD	R1,X#1
	LOAD	R2,Y#1		Cover at least 1 cycle of load latency
	MUL	R1,R1,R3	assuming R3 has the constant
	LOAD	R4,X#2		Start getting next element of X
	LOAD	R5,Y#2		Start getting next Y, to cover MUL
	ADD	R1,R1,R2	A*X+Y, MUL was done
	MUL	R4,R4,R3	Start A*X for 2nd X
	STOR	R1,D#1		Store result of first A*X+Y
	LOAD	R1,X#3		Start on next one.... etc ,etc

On most aggressive machines, there is at least 1 cycle of load latency,
and FP MULs and ADDs take more than one cycle.  Consider the example above
(i.e., LOAD takes 2 cycles, MUL takes 3, ADD 2, STORE 1, but all overlappeable),
then a well-compiled & unrolled DAXPY approaches 6 cycles/element.
The "equivalent" stack machine of the style described would tend towards
11:
	dup	1
	lod+mul	2+3
	lod+add	2+2
	store	1
	------	11
I suppose you could hide a few cycles if you started the lod+add earlier,
at the expense of a more complex design ... but the best you'd get from this
code, in a single-issue machine, would be:

	dup	1
	lod+mul	2+3
	lod+add	0+2		Assume lod issued early so data is ready for add
	store	1
	------	9

Hence, you suffer 50-80% additional cycles from similar-speed functional
units ....  and this, in a case in which there is only one item worth
keeping in a register, unlike the many cases where there are more.

The point is that the very thing that makes the stack machines nice (for
code density, using implied addresses) makes it difficult to do the
kinds of register allocation and overlapping that current systems do.
If you try to hide the load latencies, you find you get a large
increase in the number of DUPS.

There are plenty of codes around in which compilers find good use for 16
FP registers, and in fact, people complain bitterly for more, which is
why the current RISCs mostly support 32...

Re: T9000: 1991's Hot CHips' T9000  [which applies various techniques
to get around the issues described above] was described as being available
1Q92 in the paper.  Does anybody know if it's out yet?


-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 94039-7311