🚀 go-pugleaf

 Bruce Hoult writes:
| usenet@lowry.eche.ualberta.ca (Brian Lowry) writes:
| > > dmult   ;
| > >         MulLW   R6,R3,R4                ; Generate low word of result
| > >         StW     R6,4(R5)                ; Save result
| > >         MulHWU  R7,R3,R4                ; Generate high word of result
| > >         StW     R7,0(R5)                ; Save result
| > >         BLR                             ; Return to caller

 [vs]

| > MulLW   R6,R3,R4                ; Generate low word of result
| > MulHWU  R7,R3,R4                ; Generate high word of result
| > StW     R6,4(R5)                ; Save result
| > StW     R7,0(R5)                ; Save result
| > 
| > would be more efficient.  If anyone can spare the time to clue me in on
| > the finer points of PPC assembly, I'd appreciate it (not that I mind
| > programming in C/C++, but occasionally it seems somewhat inefficient...)
| 
| You'd think so, but unfortunately on the PPC601 the integer mul instructions
| aren't pipelined and they stall the next instruction until they have
| completed.
| 
| If a future PPC chip has either a) pipelined integer mul, or b) two or more
| integer ALUs capable of doing muls at the same time, then you would be
| correct.

The 604 has a pipelined integer multiply, but scheduling instructions as in  
example 2 won't be any better, and may actually be worse than as in example 1.

This is because the 604 has:
	reservation stations on the front of all functional
	units, so it can accept dispatched instructions before the operands
	are ready

	separate load/store and complex integer (multiply/divide)
	units

	a finished store queue that pulls stores out of the execution stream
	and holds them until they are ready to complete

Because the 604 can only dispatch one instruction per functional unit per  
cycle, putting multiply instructions back-to-back will guarantee that only one  
instruction will be dispatched per cycle.  However, by interleaving  
instructions executed in different functional units, multiple instructions can  
be dispatched, which may allow the code to execute and finish sooner (not  
dispatch limited).

Both of the sequences above, when put in a BDNZ loop, will execute a loop  
iteration in 3 clock cycles on a 604.  If, however, we extend the loop by  
performing two more multiplies and stores, we find:

loop1:					loop2:
	mullw	r6, r4, r5			mullw	r6, r4, r5
	stw	r6, -4(sp)			mulhwu	r7, r4, r5
	mulhwu	r7, r4, r5			mullw	r8, r4, r5
	stw	r7, -8(sp)			mulhwu	r9, r4, r5
	mullw	r8, r4, r5			stw	r6, -4(sp)
	stw	r8, -12(sp)			stw	r7, -8(sp)
	mulhwu	r9, r4, r5			stw	r8, -12(sp)
	stw	r9, -16(sp)			stw	r9, -16(sp)
	bdnz	loop1				bdnz	loop2
[5 clock ticks per loop]		[7 clock ticks per loop]

This is because loop1 is only limited by functional unit performance (data  
flow), but loop2 is further throttled by dispatch limitations.

--
	-- Tim Olson
	Apple Computer Inc. / Somerset