Re: [Qemu-devel] [PATCH V2] softfloat: Rename float*_is_nan() functions to float*_is_quiet_nan()

[Andreas Färber]

Am 18.12.2010 um 11:39 schrieb Peter Maydell:

> On 18 December 2010 02:30, Nathan Froyd <address@hidden>  
> wrote:
> > I wouldn't be too worried:
> >
> > typedef uint8_t flag;
> > typedef uint8_t uint8;
> > typedef int8_t int8;
> > typedef int uint16;
> > typedef int int16;
> > typedef unsigned int uint32;
> > typedef signed int int32;
> > typedef uint64_t uint64;
> > typedef int64_t int64;
> >
> > So adding _t suffixes in appropriate places should be a no-op, except
> > for uint16/int16--and those types are never used.
>
> Eh? If you comment out the int16 typedef you'll find softfloat.c
> doesn't compile because of all the places it's used... (uint16
> isn't used, though.) A lot of the int16 uses are things like shift  
> counts
> which should probably go to plain old 'int' rather than 'int16_t'.
>
> Also, are we sure we want to throw away the current information
> in the code about the distinction between "I need at least X bits"
> and "I need exactly X bits" ?

IMO a lot of code in QEMU is cryptic because someone thinks that  
someone else must've thought something particular when doing it that  
way and is thus reluctant to touch it...

For a fact, [u]int8 und [u]int64 remain unchanged width-wise.
For [u]int16, only malc may know what that maps to on AIX, for which  
they are #ifndef'ed out. I doubt it's an int.
Unless there's an ILP64 platform we support, [u]int32 would stay the  
same width, too.
That's why I was saying, putting, e.g., a 33rd bit into int32 has  
undefined semantics, just as for the POSIX int_least32_t type. I don't  
see a win in declaring that information.

My patch tries to do three things in one:
1.) Fix mismatches between headers and sources, i.e. float32  
int32_to_float32(int); vs. float32 int32_to_float32(int32) {...} etc.
2.) Drop the unnecessary custom integer types in favor of standard ones.
3.) Fix instances of lazyness where _t was forgotten and the mistake  
was hidden by the softfloat typedefs.

Renaming int32 to qint32 would defeat the second purpose. I got around  
the Haiku issue for now, so that's not a pressing need.

Had the softfloat code not been a real refactoring-unfriendly mess of  
int, int* and int*_t, I would've offered to do this in multiple steps  
per type. I could try splitting out part 1 above. Part 3 can easily be  
split off by cut-and-paste and could be applied independently.

Promoting int16[_t] to int for things like shift counts is beyond the  
scope of my patch.

Andreas