[Top][All Lists]

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

Re: [Qemu-devel] softfloat breaks cocoa.m

From: Peter Maydell
Subject: Re: [Qemu-devel] softfloat breaks cocoa.m
Date: Fri, 2 Sep 2011 17:38:26 +0100

2011/8/28 Peter Maydell <address@hidden>:
> On 28 August 2011 14:02, Alexander Graf <address@hidden> wrote:
> There are two ways we can fix the naming clash here:
> (1) change int16 -> int_fast16_t. This was argued against because
> it means that the type might have a different width depending on
> the host system, which means that where softfloat buggily makes
> assumptions about the typewidth this would surface only on the
> minority of systems where (eg) int_fast16_t wasn't 32 bits.
> (In theory this is just preserving current behaviour but in fact
> the set of typedefs in softfloat.h doesn't take advantage of the
> "may be bigger" leeway; for example we 'typedef int8_t int8' even
> though the comment above specifically suggests that int8 should
> be typedef'd as an int.)
> (2) change int16 -> int16_t. This was argued against because it
> would be dropping the information in the current softfloat code
> about where we require a 16 bit type for correctness and where
> we are happy for the type to be larger if it's more efficient.

I think I was the main advocate for (1) here. If somebody felt
like doing a quick benchmark of int*_t vs int_fast*_t (just some
simple floatingpoint benchmark on a linux-user target that uses
TCG and softfloat) that might help break the deadlock one way
or the other. If there's no real difference in speed then I'd
be willing to see us take option (2) instead.

-- PMM

reply via email to

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