Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.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: Sun, 15 Sep 2024 20:48:48 +0200
Organization: A noiseless patient Spider
Lines: 53
Message-ID: <vc7a6h$2afrl$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 15 Sep 2024 20:48:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0f814bd11c9fbe5b78942ec153f06f57";
	logging-data="2441077"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/+JiCSAzPgx95ho/zKOMOQxvcLqYgFlvs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:hW+ticd0aGgarY/tH52OyyDbwB8=
In-Reply-To: <32a15246310ea544570564a6ea100cab@www.novabbs.org>
Content-Language: en-GB
Bytes: 3912

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.)