🚀 go-pugleaf

In article <1992Nov18.181014.1667@Princeton.EDU> awolfe@moo.Princeton.EDU (Andrew Wolfe) writes:
...
>
>My students and I are confused about the way that traps are handled in
>SPARC implementations with multi-cycle, unpipelined FP operations.  I
>can't find anything in the SPARC arch. ref. that says anything
>different.  Here is our problem.  If you only save the instructions and
>PCs of uncompleted operations, then how do you get the input operands
>to re-execute them.  For example if instruction-2 requires r7, but
>instruction-n (that has completed) overwrites r7 then how can I restart
>instruction 2?
>
>It would seem that a history buffer of some type containing register
>values is still required.
>
On the SS1 and the IPX, there is no history buffer. I believe the way
this is handled is that instructions which have dependencies like your
example are interlocked. In your example, instruction-n would not 
start execution until instruction-2 finishes. When an instruction
has a fault, results are not written back to the register file. 
So the only thing that is imprecise is that some instructions 
may have completed out of order. No source registers for uncompleted
instructions will have been modified.

On the SS1 and the IPX, you can only really have two floating point
operations (of different types) executing at a time, and of course the
FPU and IU have separate register files, so this is not a big
performance hit.

I belive that the SS2 trap handling is very similar to SS1. I 
have not yet heard about trap handling on the SuperSPARC. There
is more that can be going on in a single cycle on that one, so
I would expect something more complicated would be necessary 
to avoid an excessive number of stalls.

Michael Weaver.