Re: [Qemu-ppc] ppc: TCG and FP exceptions, is it right ?

[Richard Henderson]

On 07/25/2016 03:14 PM, Benjamin Herrenschmidt wrote:
> The code as writte will take the exception before the FPR is updated,
> I *think*, or am I missing something here  ?

You are correct, exceptions are raised from e.g. helper_fadd before the 
writeback to the fp register.

> What do you think is the most appropriate implementation here?

Something like the sparc implementation.

We compute the value with one helper, exception bits are kept in the fp_status 
struct.  Writeback to the register happens at the end of the call to the first 
helper.  We then immediately call a second helper, 
helper_check_ieee_exceptions, which takes the data from fp_status and produces 
the appropriate sparc status bits and raises whatever exceptions are required.

> I'm thinking it's almost worth bringing FE0/FE1 into the hflags
> so that we know at translation time whether to be precise, imprecise,
> or ignore FP exceptions.

Precise or imprecise probably doesn't matter (I haven't figured a good way to 
exploit that for Alpha; not that I'm trying anymore, since ev67, which I 
emulate the most, requires precise exceptions).

But being able to know that no exceptions can be raised may be helpful.  One 
can mark the helpers as not reading all global registers, which avoids 
unnecessary memory traffic to env.

> Then we could do something along the lines of:
>
>   - In the helpers, when checking status, set an env flag if an
> exception should occur.
>
>   - In all the translate call sites, if FE0/1 is non-0 (at translate
> time), generate call to check that flag and shoot the exception

This is another plausible implementation.  I'd have to look back at the manual 
to give more specific suggestions.

> An additional note is that if FE0/FE1 are 0, we still in some case
> leave an exception behind in cs->exception_index. Now, I *think*
> that's ok, it will just be silently dropped at some point, but I am not
> 100% certain as that's a part of TCG I'm an not super familiar with
> yet.

That should be fine.  All exits from the loop should set a new value here as 
they exit.


r~