Re: [Qemu-devel] [PATCH v5 04/10] softfloat: Drop [u]int16 types in favor of [u]int_fast16_t

[Aurelien Jarno]

On Tue, Mar 08, 2011 at 08:29:50AM +0000, Peter Maydell wrote:
> On 7 March 2011 23:37, Aurelien Jarno <address@hidden> wrote:
> > I understand your point, but OTOH int_fast16_t means at least int16_t so
> > in practice it doesn't bring anything more than changing to int16_t,
> > except more pain as the size actually depends on the host.
> 
> But at the moment we implement int16 as int, so (a) we'd be telling
> the compiler it needed to use a type that was (fractionally) less
> efficient and (b) we already know that the code can cope with the
> type being wider than 16 bits, because that's how we're compiling
> the code today. The thing we should be worrying about is that maybe
> there's code that accidentally requires more than 16 bits in an
> int16 which would break if you defined it as an int16_t...

And it might also break with int_fast16_t as it only guarantees int16_t
at the minimum. So using int_fast16_t doesn't bring more safety than
int16_t here.

Also currently we define int16 as int, so it has the same size
everywhere. int_fast16_t size is varying depending on the host.

> 
> > If we want to change the int here, we should either use int32_t here
> > (which matches the size of int), or just look case by case and use the
> > correct type.
> 
> Correct choice between 'bits16' and 'uint16' is actually one of
> the areas where I pretty much trust the original softfloat code:
> I think it's definitely a retrograde step to throw that away,
> and personally I would NAK any patch which merges the two together
> into a single typename.

On most systems uint_fastxx_t types is defined in the preprocessor, so
the compiler can't really exploit this. We are in 2010 and compilers are
able to compile code using 16-, 32- or 64-bit ops for an uint16_t if 
it's faster on this architecture, while guaranteeing that the result 
would be the same than an uint16_t. By using uint_fast16_t we simply
force the compiler to use a 64-bit op on a 64-bit machine, even if it
has only have 16-bits to handle. Also a lot of functions in softfloat
are static or inline functions, so the compiler can do a lot of 
optimizations if the type is not overestimated.

In any case, I would NAK any patch that are using different size
depending on the host, as it is a real nightmare to handle, and there is
no real point to do that. Andreas has shown we can have code that compiles 
on 32-bit, but not on 64-bit. That's the best case, we can also have 
different results on 32-bit than 64-bit, and it's a lot more difficult to
detect.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net