RE: [fpu] FPU operations

[Damjan Lampret <damjanlampret@yahoo.com>]

> 
> If you want a cmp to be performed on the result of an operation,
> against
> what would you want it to be compared ?
> 

Result vs zero. Is it greater, lesser or equal (actually LT(GT) and EQ
are enough to always know GT(LT)).

> I think we should definitely provide a status signal for "zero", so
> right 
> after an FP OP, a conditional jump could follow. Similar like
> you might do with 'unordered' and 'infinity' outputs, which will also
Sure. Maybe also for GT(LT)? Would this affect performance?

> 
> Right, you do not check if the 'unordered' bit is set and then set
> another 
> flag and then jump based on that flag. No I imagined that
> the jump inst. will have the condition coded in to it. Right ?

Exactly.

> 
> >compare when you want to compare when status of operation is already
> >overwitten by following operation. You know what I am talking - just
> >like in most CISCs.
> 
> Ahm, no, I think this is wrong. The status/result, should never be
> overwritten. You must latch the output *to* the FPU, and keep it
> until a
> new FP OP is performed. Otherwise it's a nightmare to track the
> results.
> That way you can always look at the status flags from the FPU and
> know
> they are from the last FP OP.
> 
Oh, I thought FPU would latch results. OK, so FPU only registers them
(I mean on clk edge) and CPU latches them. This is also fine.

--damjan


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/