Re: Computer architects leaving Intel...

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>