Re: Computer architects leaving Intel...

On 15/09/2024 21:13, MitchAlsup1 wrote:

On Sun, 15 Sep 2024 18:48:48 +0000, David Brown wrote:
 

On 15/09/2024 19:21, MitchAlsup1 wrote:

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; /**< R/W1C/H - RAM
ECC DBE detected. */
        uint64_t reserved_9_31               : 23;
        uint64_t sbe                         :  9; /**< R/W1C/H - RAM
ECC SBE detected. */
#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.

>
You do so inconveniently, perhaps with access inline functions rather
than a bit-field struct.
>
Fortunately, not many hardware designers are that sadistic.  (Or perhaps
they /are/ that sadistic, but lack the imagination for that particular
trick.)

 In My 66000 ISA it is both efficient and straightforward::

That does not change that it is inconvenient in C, which is what you asked about.  For any ISA, there will always be things that can easily written in C that are awkward in assembly, and vice versa.

      i = struct.field;
..
     struct.field = j;
      CARRY    Rsf1,{I}
     SRA      Ri,Rsf0,<17,53>
and
     CARRY    Rsf1,{O}
     INS      Rsf0,Rj,<52,17>
 Note: Rsf1 and Rsf0 combined are the 128 bits container, but there is no
need for these registers to be sequential.
 As to HW sadism:: this not not <realistically> any harder than mis-
aligned DW accesses from the cache. Many ISA from the rather distant
past could do these rather efficiently {360 SRDL,...}
 

Anyone who designs a data structure with a bit-field that spans two 64-bit parts of a struct is probably ignorant of C bit-fields and software in general.  It is highly unlikely to be necessary or even beneficial from the hardware viewpoint, but really inconvenient on the software side (whether you use bit-fields or not).
Some hardware designers seem to have no understanding of or consideration for the software folks that will use their designs.  "HW Sadism" is no doubt too strong a term - ignorance and a lack of consideration is more realistic.

If the ISA has any realistically efficient grasp on multi-precision
integer operations, these fall out almost for free.

I can't see that.  I am not saying you are wrong, but I don't see the connection.