From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vy0a0-00051w-QV for qemu-devel@nongnu.org; Tue, 31 Dec 2013 09:46:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vy0Zv-0002QE-P1 for qemu-devel@nongnu.org; Tue, 31 Dec 2013 09:46:00 -0500 Received: from mail-lb0-f180.google.com ([209.85.217.180]:46370) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vy0Zv-0002Q0-Hd for qemu-devel@nongnu.org; Tue, 31 Dec 2013 09:45:55 -0500 Received: by mail-lb0-f180.google.com with SMTP id x18so6233468lbi.39 for ; Tue, 31 Dec 2013 06:45:54 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <52C2D61E.4000804@twiddle.net> References: <1388496958-3542-1-git-send-email-peter.maydell@linaro.org> <1388496958-3542-4-git-send-email-peter.maydell@linaro.org> <52C2D2E2.7070203@twiddle.net> <52C2D61E.4000804@twiddle.net> From: Peter Maydell Date: Tue, 31 Dec 2013 14:45:34 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 03/22] softfloat: Add 16 bit integer to float conversions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: Tom Musta , Peter Crosthwaite , Patch Tracking , Aurelien Jarno , Michael Matz , Alexander Graf , QEMU Developers , Claudio Fontana , Dirk Mueller , Will Newton , Laurent Desnogues , =?UTF-8?B?QWxleCBCZW5uw6ll?= , "kvmarm@lists.cs.columbia.edu" , Christoffer Dall On 31 December 2013 14:35, Richard Henderson wrote: > On 12/31/2013 06:27 AM, Peter Maydell wrote: >> The existing int32_to_float* functions take int32, not int32_t, >> so this is the same semantics. You could argue that it would >> be better for all of them to take the exact type rather than >> the at-least-this-big type (it would let me drop a cast in the >> ARM code that calls these), I suppose. > > Yes, that's what I'm arguing. Of course, I'd forgotten that we already have > that problem, since my eyes refuse to see the lack of "_t" there. But is that > existing bug any reason to extend the problem? OK, let's make this one return int16_t. I may throw in an extra patch making the other int-to-float routines take the precise types too. > One of these days we should just clean up all the crap formatting, bogus types, > and stupid STATUS_* macros... Yes, the STATUS_ stuff is definitely on my list to zap, once we get all this stuff reviewed and committed (since it would otherwise cause conflicts all over the place). I think the standing question about the types is whether we should be converting int32 to int32_t or int_fast32_t (and indeed whether it makes much performance difference). That's why we have the current setup where some of the intfoo got changed to int_fastfoo_t and some didn't. My other hope for this year is that we can clear up the relicensing stuff so I don't have to keep prodding people about specifying the 2a-or-2b stuff on new patches... thanks -- PMM