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.