[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose struct
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures |
Date: |
Thu, 18 Jan 2018 11:59:19 -0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 |
On 01/18/2018 11:31 AM, Peter Maydell wrote:
> On 18 January 2018 at 14:26, Philippe Mathieu-Daudé <address@hidden> wrote:
>> Le 18 janv. 2018 10:09 AM, "Alex Bennée" <address@hidden> a écrit :
>> Philippe Mathieu-Daudé <address@hidden> writes:
>>>> +typedef struct {
>>>> + uint64_t frac : 64;
>>>
>>> I think this does not work on LLP64/IL32P64 model.
>>>
>>> Should we add a check in ./configure and refuse to build on IL32P64
>>> model? This would be safer IMHO.
>>>
>>>> + int exp : 32;
>>>> + float_class cls : 8;
>>>> + int : 23;
>>>> + bool sign : 1;
>>>
>>> checking on "ISO/IEC 14882:1998" 9.6 Bit-fields:
>>>
>>> Alignment of bit-fields is implementation-defined. Bit-fields are packed
>>> into some addressable allocation unit. [Note: bit-fields straddle
>>> allocation units on some machines and not on others. Bit-fields are
>>> assigned right-to-left on some machines, left-to-right on others. ]
>>>
>>> I'd still write it:
>>>
>>> int :23, sign :1;
>>>
>>>> +} decomposed_parts;
>>
>> I think rather than stuff it into bit fields we can just leave it up to
>> the compiler?
>>
>>
>> Yep, my only worry here is the IL32P64 model, if we care.
>
> I don't think we care much about IL32P64, but the code should
> still work there, right? It doesn't actually make any assumptions
> about bitfield layout.
My comment was for a previous line:
uint64_t frac : 64;
I don't have enough compiler knowledge to be sure how this bitfield is
interpreted by the compiler. I understood the standard as bitfields are
for 'unsigned', and for IL32 we have sizeof(unsigned) = 32, so I wonder
how a :64 bitfield ends (bits >= 32 silently truncated?).
Richard do you have an idea?
>
> I think I agree that we shouldn't use bitfields here if we don't
> need to, though.
>
> thanks
> -- PMM
>
- Re: [Qemu-devel] [PATCH v2 07/20] fpu/softfloat: propagate signalling NaNs in MINMAX, (continued)
[Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures, Alex Bennée, 2018/01/09
- Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures, Richard Henderson, 2018/01/09
- Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures, Peter Maydell, 2018/01/12
- Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures, Philippe Mathieu-Daudé, 2018/01/12
- Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures, Alex Bennée, 2018/01/18
- Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures, Philippe Mathieu-Daudé, 2018/01/18
- Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures, Peter Maydell, 2018/01/18
- Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures,
Philippe Mathieu-Daudé <=
- Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures, Peter Maydell, 2018/01/18
- Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures, Alex Bennée, 2018/01/23
[Qemu-devel] [PATCH v2 11/20] fpu/softfloat: re-factor add/sub, Alex Bennée, 2018/01/09
[Qemu-devel] [PATCH v2 14/20] fpu/softfloat: re-factor muladd, Alex Bennée, 2018/01/09
[Qemu-devel] [PATCH v2 16/20] fpu/softfloat: re-factor float to int/uint, Alex Bennée, 2018/01/09