|
From: | Andreas Färber |
Subject: | Re: [Qemu-devel] [PATCH V2] softfloat: Rename float*_is_nan() functions to float*_is_quiet_nan() |
Date: | Sat, 18 Dec 2010 12:49:03 +0100 |
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... (uint16isn't used, though.) A lot of the int16 uses are things like shift countswhich 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
[Prev in Thread] | Current Thread | [Next in Thread] |