From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58174 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PU10e-0000fr-GV for qemu-devel@nongnu.org; Sat, 18 Dec 2010 12:55:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PU10d-0000vK-5D for qemu-devel@nongnu.org; Sat, 18 Dec 2010 12:55:56 -0500 Received: from fe01x03-cgp.akado.ru ([77.232.31.164]:50584 helo=akado.ru) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PU10c-0000v8-O2 for qemu-devel@nongnu.org; Sat, 18 Dec 2010 12:55:55 -0500 Date: Sat, 18 Dec 2010 20:55:44 +0300 (MSK) From: malc Subject: Re: [Qemu-devel] [PATCH V2] softfloat: Rename float*_is_nan() functions to float*_is_quiet_nan() In-Reply-To: <399990E2-021F-40D3-8787-542379592760@web.de> Message-ID: References: <1292601366-990-1-git-send-email-peter.maydell@linaro.org> <5C19C2AC-87D5-4C9E-8D8D-E2FEC4AC89F5@web.de> <20101218023011.GN25059@nightcrawler> <399990E2-021F-40D3-8787-542379592760@web.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Andreas_F=E4rber?= Cc: Peter Maydell , QEMU Developers , Nathan Froyd , "Edgar E. Iglesias" On Sat, 18 Dec 2010, Andreas F?rber wrote: > Am 18.12.2010 um 11:39 schrieb Peter Maydell: > > > On 18 December 2010 02:30, Nathan Froyd 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. AIX leaks all sorts of stuff from system headers, i don't remember what int16 is defined as. > 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 -- mailto:av1474@comtv.ru