[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 03/22] softfloat: Add 16 bit integer to float co

From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 03/22] softfloat: Add 16 bit integer to float conversions
Date: Tue, 31 Dec 2013 14:45:34 +0000

On 31 December 2013 14:35, Richard Henderson <address@hidden> 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...

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]