Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions

[Richard Henderson <rth@twiddle.net>]

On 06/25/2014 10:55 PM, Al Viro wrote:
> On Wed, Jun 25, 2014 at 08:01:17AM +0100, Al Viro wrote:
>> On Tue, Jun 24, 2014 at 02:32:46PM -0700, Richard Henderson wrote:
>>> On 06/24/2014 02:24 PM, Al Viro wrote:
>>>> Al, off to figure out the black magic TCG is using to generate calls...
>>>
>>> If you've a helper
>>>
>>> DEF_HELPER_1(halt, void, i64)
>>>
>>> then
>>>
>>>   gen_helper_halt(...)
>>>
>>> will generate the tcg ops that result in the call.
>>
>> Another fun issue:
>>
>> CVTTQ is both underreporting the overflow *AND* reports the wrong kind - FOV
>> instead of IOV.
>>
>> 	* it misses reporting overflows for case when it *knows* that
>> 	  overflow will happen - the need to shift up by more than 63 bits.
>> 	  Trivially fixed, of course.  There overflow cases leave wrong
>> 	  result as well - should be 0.
>> 	* it also misses reporting overflows for case when value is in
>> 	  ranges 2^63..2^64-1 and -2^64+1..-2^63-1.  And yes, it's
>> 	  asymmetric - 2^63 is an overflow, -2^63 isn't.
>> 	* overflow is reported by float_raise(float_flag_overflow, &FP_STATUS).
>> 	  Wrong flag - it should be IOV, not FOV.  And it should be set
>> 	  in FPCR regardless of the trap modifier (IOV, this VI thing is
>> 	  wrong - we should deal with that only when we generate a trap).
>> 	* All overflow cases should raise INE as well.
>>
>> Could we steal bit 1 in float_exception_flags for IOV?  It is (currently?)
>> unused -
>> enum {
>>     float_flag_invalid   =  1,
>>     float_flag_divbyzero =  4,
>>     float_flag_overflow  =  8,
>>     float_flag_underflow = 16,
>>     float_flag_inexact   = 32,
>>     float_flag_input_denormal = 64,
>>     float_flag_output_denormal = 128
>> };
>>
>> That would allow to deal with that crap nicely - we could have it raise
>> the new flag, then have helper_fp_exc_raise_... for default trap mode
>> mask it out (and yes, we need to set FPCR flags in default mode, as well
>> as /U and /V - confirmed by direct experiment *and* by TFM).
> 
> OK, I've managed to resurrect UP1000 box (FSVO resurrect - the southbridge
> DMA controller has always been buggered, with intermittent noise on one of
> the data lines; fans in CPU module are FUBAR as well - 17 and 20 RPM resp.,
> so I don't risk keeping it running for long, etc.)
> 
> Still, that allows to test EV67 and I hope to resurrect a DS10 box as well,
> which will allow for saner testing environment.
> 
> Current delta follows, fixing gcc and libc testcases *and* AFAICS getting
> CVTTQ handling in line with what actual EV67 is doing.  It's a dirty hack
> wrt float_raise() - relies on bit 1 never being raised by softfpu.c.  I'll
> look into separating that bit, but it'll probably have non-zero costs ;-/
> We need two flags - "has IOV been raised during this insn" (in this patch
> it's bit 1 of fp_status.float_exception_flags, cleaned along with those)
> and something to keep FPCR.IOV in (in this patch - bit 1 of fpcr_exc_status).
> Sure, we can add another uint8_t or two in struct CPUAlphaState, but that'll
> mean extra PITA in code and extra memory accesses...
> 
> Review would be welcome.

Looks good.

I've split it up into a couple of smaller patches, made some sylistic tweaks
and pushed it to

  git://github.com/rth7680/qemu.git axp-next

I'm starting to do some testing now, but a glance though would be helpful.
Especially to see if I didn't make some silly mistake in the process.


r~