[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] IEEE FP exceptions



On Wed, 05 Mar 2003 20:38:18 +0100
Yann Guidon <whygee@f-cpu.org> wrote:

> hi,
> 
> Michael Riepe wrote:
> 
> >On Wed, Mar 05, 2003 at 10:25:38AM +0100, devik wrote:
> >[...]
> >
> >  
> >
> >>all FP would set hidden flag of result register on computation
> >>error and then you could check it. You could not need to serialize
> >>FP at all.
> >>    
> >>
> >
> >What if you use an integer instruction to modify the result?  E.g.
> >clear or change the sign bit (fabs/fneg), modify the exponent
> >(fscale) and such?  They won't be aware of the extra bit, and won't
> >maintain it(or probably reset it to 0).  We would have to check the
> >`fpex' flag with an explicit `jmp.fpx' or `move.fpx' instruction
> >(which would replace the current `jmp.nan'/`move.nan').
> >  
> >
> 
> argh ....
> 
> This last conditional code seems to be very attractive but it looks
> like nobody is agreeing for its use....
> 

Discuss is on going.

> 
> Another problem is to do something realistic and that can be
> implemented : NaN is a condition that can be easily found from
> "decoding" the FP data. Well, now there is the problem : is it for 32
> bits or 64 bits FP ? and what about
> the SIMD versions ?
> On top of that, if an "FP exception" condition (which has a similar
> role to NaN)
> is implemented, how can this be decoded ?
> If an additional bit is necessary for the context swap, it's not 
> possible to implement it
> because its restoration will be impossible. That's why i proposed NaN
> as an error condition
> But this could be more general, with +/- infinite and other things.
> 
> 
> >>Alternate way is to have clear_fpex & is_bad_fp as global (aby
> >>FP would write to single status register) and then both of
> >>these would need to be FP barrier.
> >>    
> >>
> >
> >I prefer the non-serializing variant, with the option that the CPU
> >may trap if the flag is set on any of the input operands of an FP
> >instruction(just like it will do when the zero flag is set on a
> >divisor).  That means that the flag should go into the scoreboard.
> >
> >We can also provide some bits in the FPU control register that
> >specify when the fpex flag will be set (to exclude conditions that
> >aren't interesting, e.g. inexact result or gradual underflow).
> >
> >The remaining problem is that the fpex flags must be saved and
> >restored when a task switch occurs, either automatically or with an
> >explicit special instruction.
> >
> >Another question is:  What do we do in SIMD mode?  Use a single flag
> >for all chunks?
> >
> i think that this question is even more important and challenging than
> the condition problem....
> 

I beleive that all the chunk should be traited the same. So you will
change the code for all the data, so a bit for a single vector
("there was at least one NaN").

> YG
> 
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/