On 31 December 2013 14:21, Richard Henderson <rth@xxxxxxxxxxx> wrote:
> On 12/31/2013 05:35 AM, Peter Maydell wrote:
>> +/* We provide the int16 versions for symmetry of API with float-to-int */
>> +INLINE float32 int16_to_float32(int_fast16_t v STATUS_PARAM)
>> +{
>> + return int32_to_float32(v STATUS_VAR);
>> +}
>
> If you're going to have int16 versions, I don't think you should use
> int_fast16_t, but rather int16_t so that we will properly truncate the incoming
> value. Otherwise there's not much point in having these, IMO.
I was going for consistency with the convert-to-int16, which return
int_fast16_t. The benefit of having these functions is that the
caller doesn't have to effectively have an extra bit of logic in
its macros to say "conversion from 32 bit int is int32_to_float32,
conversion from 64 bit int is int64_to_float32, but conversion
from 16 bit int is not int16_to_float32".
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.
> And please add blank lines between the functions.
Sure.
thanks
-- PMM
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
