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

[Aurelien Jarno]

On Mon, Mar 07, 2011 at 11:14:11PM +0000, Peter Maydell wrote:
> On 7 March 2011 09:56, Aurelien Jarno <address@hidden> wrote:
> > On Mon, Mar 07, 2011 at 01:34:07AM +0100, Andreas Färber wrote:
> >> AIX already didn't use our definition, so let's start ripping out this one:
> >> As pointed out by Peter Maydell, int16 is currently int on most
> >> supported platforms, so let's replace it with int_fast16_t,
> >> allowing the system to use a wider type if appropriate.
> >
> > Do you have a rationale about the use of the fast version of the types?
> > As you said it allows the compiler to use a wider type if appropriate,
> > and this usually doesn't play very well when shifts are involved, which
> > is the case of the softfloat code. Have you verified that each
> > conversion is correct? On the other hand I really doubt it has a
> > measurable impact on speed.
> >
> > I would really go for uint16_t for now. This might be changed to the fast
> > version in a second step if we are sure everything is correct, but let's
> > don't mix the two steps for now.
> 
> As Andreas says, the code as it is at the moment makes the "wider
> is OK" vs "exact width only" distinction, it just isn't using the
> standard typenames to do it. So changing "int16" to "int16_t" would
> be the change of semantics (both in theory and in practice, since at
> the moment "int16" is int).
> 

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.

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.

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