Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sun, 15 Sep 2024 19:13:31 +0000
Organization: Rocksolid Light
Message-ID: <50cd3ba7c0cbb587a55dd67ae46fc9ce@www.novabbs.org>
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> <vc7a6h$2afrl$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2187741"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$ghuEO5eIZXMLSgeNqFJWFu8dHF8fp/NgGbvPtuvRmRv6xsR771k2W
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 4576
Lines: 74

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::

     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,...}

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