qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] target-i386/FPU: wrong conversion infinity from


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] target-i386/FPU: wrong conversion infinity from float80 to int32/int64
Date: Mon, 14 Jul 2014 15:59:18 +0100

On 14 July 2014 15:35, Dmitry Poletaev <address@hidden> wrote:
> I executed test-i386 from tests folder from QEMU rep and according to the 
> result, instructions fistl and fistpll returns maximum positive result 
> (0x7fff...), if a FPU register stores a positive infinity, and minimum 
> negative result (0x80...), if a negative infinity stores in a register. Real 
> processor in both cases returns minimum negative result (0x80...). An Intel 
> manual(Vol. 2A 3-299 
> (http://www.intel.ru/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-2a-manual.pdf))
>  tells us "If the invalid-operation exception is masked, the integer 
> indefinite value is stored in memory." I not found what "integer indefinite 
> value" obviously means, but I make conclusion that "integer indefinite value" 
> is 0x8000...
>
> This patch fixes behaviour of fistl/fistpll instructions correct, and at 
> least not adds new bugs(according to tcg tests), but I am not shure it 
> doesn't breaks anything.

Yeah, this seems pretty likely to break all our other architectures
that use softfloat. (ARM at least gives MAXINT for +infinity
and MININT for -infinity.) This needs to either be done in the
target-i386/ code or by adding an option flag of some sort
to softfloat to permit the i386 code to specify the required
behaviour. (I checked the IEEE 754 spec and it looks like the
result value isn't specified for overflows, so this is all going
to be architecture-specific.)

The "integer indefinite value" is defined in volume 1 of the
Intel Architecture Software Developer's Manual, in table 4-1
(and also section 8.2.1); it is indeed a value with only the
most significant bit set.

I think that given that the manual says this is only done for
FIST/FISTP I would start by trying to deal with this in the
target-i386 code for those insns: call the softfloat conversion
function as usual, but if it sets the invalid flag then ignore
what softfloat returns you and use the integer-indefinite-value
instead. (Since softfloat's status flags are sticky you may need
to do a save-old-flag-value/clear-flags/softfloat op/check-flags/
merge-flag-values dance.)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]