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
>> t
On 12/31/2013 06:27 AM, Peter Maydell wrote:
> I was going for consistency with the convert-to-int16, which return
> int_fast16_t.
Perhaps, but in that case we've properly bounded the result; it's guaranteed to
be in range of int16_t.
> The existing int32_to_float* functions take int32, not int32
On 31 December 2013 14:21, Richard Henderson 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);
>>
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 yo
Add the float to 16 bit integer conversion routines. These can be
trivially implemented in terms of the int32_to_float* routines, but
providing them makes our API more symmetrical and can simplify callers.
Signed-off-by: Peter Maydell
---
include/fpu/softfloat.h | 17 +
1 file ch
