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

[Al Viro <viro@ZenIV.linux.org.uk>]

On Wed, Jun 25, 2014 at 10:27:11AM +0100, Peter Maydell wrote:

> I think it's OK to put extra float_flags in, provided you can define
> their semantics in terms that make sense for more than one
> architecture (even if only one arch actually happens to need them).
> The input_denormal/output_denormal flags only get used for ARM,
> for instance. However if you wanted to split overflow from integer
> overflow you'd need to fix up all the other targets which expect
> them to generate just one exception flag...

Hmm...  On alpha it's generated only by the following: CVTTQ, CVTGQ,
CVTQL.  I.e. conversions to integer formats that can be held in FPU
registers (double -> s64, VAX double -> s64 and s64 -> s32).  Does
softfloat even have anything similar?  As it is, it's all in alpha-specific
code; double -> s64 might have a chance to be generic (semantics:
	* denorms -> 0, raise "inexact", provided that they survived to
that point and hadn't buggered off with "invalid"
	* exact integers in range -2^63 .. 2^63-1 -> equivalent 64bit
integer
	* values outside of that range (all with zero fractional part,
since the weight of LSB of significand will be considerably greater than 1
by that point) -> lower 64 bits of value, raise "integer overflow" and
"inexact".
	* values with non-zero fractional part -> rounded according to
rounding mode, raise "inexact".
), but existing float64_to_int64() isn't it - very different behaviour
on overflows.  Incidentally, VAX double to s64 is buggered in that area -
it *does* try to use float64_to_int64() and, on top of getting INV instead
of IOV, gets the wrong result in case of overflow (MAX_LONG/MIN_LONG instead
of value in -2^63..2^63-1 comparable modulo 2^64 with exact value taken
as element of $\Bbb Z$).

And s64->s32 is just plain weird - not in the part that has IOV raised on
values outside of -2^31..2^31-1, but in the bit shuffling it's doing if
the test passes; alpha FPU stores s32 value in bits 63-62/58-29, with the
rest filled with zeroes.

In any case, it's not splitting float_overflow_flag; similar cases in
softfloat.c raise float_invalid_flag.  I don't know if it would make
sense to try and teach float64_to_int64() about this kind of return
value on overflow...

> (Note that any patch touching softfloat files needs to come with
> a statement that you're happy to license it under either the
> softfloat-2a or softfloat-2b licenses, because we're currently
> midway through the tedious process of trying to relicense it.)

Wouldn't be a problem, but I doubt that it would be particulary useful to touch
softfloat.c due to the reasons above, anyway.