🚀 go-pugleaf

tim@apple.com (Tim Olson) writes:
> 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.

That makes sense, but there are a few details missing.

1) why isn't the time for your first example 4 clock ticks per loop?
   I'm assuming this was a mistake in the following.

2) what is the latency of the integer multiply instructions?  If it is
   anywhere close to as long as for the 601 FP muls (let alone 601
   integer muls!) then why doesn't it stall on dispatching some of
   the stores?  Just how many reservation stations do you have for the
   store unit, anyway?  From that example, I assume it is at least as
   many as the latency of the multiply unit.

3) or are the dependent stores folded on top of the muls, the same way
   they are in the FP unit on the 601?

4) maybe you should say some more about the "finished store queue"

Thanks for your reply!


-- Bruce