Path: news.eternal-september.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 16 Sep 2024 11:14:52 +0200
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <vc8suc$2od19$2@dont-email.me>
References: <vaqgtl$3526$1@dont-email.me>
 <p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com>
 <2024Sep10.101932@mips.complang.tuwien.ac.at> <ygn8qvztf16.fsf@y.z>
 <2024Sep11.123824@mips.complang.tuwien.ac.at> <vbsoro$3ol1a$1@dont-email.me>
 <867cbhgozo.fsf@linuxsc.com> <20240912142948.00002757@yahoo.com>
 <vbuu5n$9tue$1@dont-email.me> <20240915001153.000029bf@yahoo.com>
 <vc6jbk$5v9f$1@paganini.bofh.team> <20240915154038.0000016e@yahoo.com>
 <vc70sl$285g2$4@dont-email.me> <vc73bl$28v0v$1@dont-email.me>
 <OvEFO.70694$EEm7.38286@fx16.iad>
 <32a15246310ea544570564a6ea100cab@www.novabbs.org>
 <86seu0d7br.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 16 Sep 2024 11:14:52 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d1583d3c65366d20e8e7bb3dd5deb61e";
	logging-data="2896937"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/5K9fu9uqYHG1VXfpeqzDQjpwwCXYngus="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:CjlWWvNjecnBXusyb37TN5RuC+Q=
In-Reply-To: <86seu0d7br.fsf@linuxsc.com>
Content-Language: en-GB

On 15/09/2024 21:51, Tim Rentsch wrote:
> mitchalsup@aol.com (MitchAlsup1) writes:
> 
>> On Sun, 15 Sep 2024 17:07:58 +0000, Scott Lurndal wrote:
>>
>>> Robert Finch <robfi680@gmail.com> writes:
>>>
>>>> On 2024-09-15 12:09 p.m., David Brown wrote:
>>>>
>>>>>> In addition, some padding-related things can be defined by Standard
>>>>>> itself.  Not in this particular case, but, for example, it could be
>>>>>> defined that when field of one integer type is immediately followed by
>>>>>> another field of integer type with the same or narrower width then
>>>>>> there should be no padding in-between.
>>>>>>
>>>>>
>>>> What about bit-fields in a struct?  I believe they are usually packed.  In
>>>> case its for something like an I/O device.
>>>
>>> That's a bit more complicated as it depends on the target byte-order.
>>>
>>> e.g.
>>>
>>>      struct GIC_ECC_INT_STATUSR_s {
>>> #if __BYTE_ORDER == __BIG_ENDIAN
>>>          uint64_t reserved_41_63              : 23;
>>>          uint64_t dbe                         :  9;
>>>          uint64_t reserved_9_31               : 23;
>>>          uint64_t sbe                         :  9;
>>> #else
>>>          uint64_t sbe                         :  9;
>>>          uint64_t reserved_9_31               : 23;
>>>          uint64_t dbe                         :  9;
>>>          uint64_t reserved_41_63              : 23;
>>> #endif
>>>      } s;
>>
>> Which brings to mind a slight different but related bit-field issue.
>>
>> If one has an architecture that allows a bit-field to span a register
>> sized container, how does one specify that bit-field in C ??
>>
>> So, assume a register contains 64-bits and we have a 17-bit field
>> starting at bit 53 and continuing to bit 69 of a 128-bit struct.
>> How would one "properly" specify this in C.
> 
> The 17-bit bitfied can be specified in the usual way.  Example:
> 
>     struct bitfield_example {
>        unsigned  one : 32;
>        unsigned  two : 20;
>        unsigned  hmm : 17;
>     };
> 
> An implementation is allowed to use up the last 12 bits of the
> first 64-bit unit and the first 5 bits of the next 64-bit unit.
> But, whether that happens or not is up to the implementation.
> The bitfield for member 'hmm' could instead be put entirely in
> the second 64-bit unit, with the last 12 bits of the first 64-bit
> unit simply left as padding.  There is no standard way to force
> it.
> 

Yes, implementations get to choose this, with most implementations 
following the specifications from the ABI for the target.

Many implementations have a way to specify tighter packing, but 
naturally this is not standardised.  But it can give a picture of the 
differences in code generation between the two options, which makes it 
easy to see why most compilers do not split bit-fields across two 
storage units.

(There is a standard way to specify that "hmm" above is /not/ packed 
across two units - adding a field "unsigned : 0;" between "two" and 
"hmm" forces this.)

<https://godbolt.org/z/sYxWjM766>