Path: ...!3.eu.feeder.erje.net!feeder.erje.net!news2.arglkargh.de!news.mixmin.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: Tue, 17 Sep 2024 11:29:15 +0200
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <vcbi5c$3ecji$2@dont-email.me>
References: <vaqgtl$3526$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>
 <50cd3ba7c0cbb587a55dd67ae46fc9ce@www.novabbs.org>
 <vc8qic$2od19$1@dont-email.me>
 <d61f7d82d6976343d9446bfc18552060@www.novabbs.org>
 <vc9sc8$2vus6$2@dont-email.me> <vcamfc$makp$2@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 17 Sep 2024 11:29:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3e52a47a8c62d553adb0a23714e2b020";
	logging-data="3617394"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19nmMtfgj+DNEaQkKuq5iG9Yr4DN42UKSs="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:ZdFz+m8gUJdQSVZ2i63lFTC5YUU=
Content-Language: en-GB
In-Reply-To: <vcamfc$makp$2@paganini.bofh.team>
Bytes: 3841

On 17/09/2024 03:36, Waldek Hebisch wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 16/09/2024 19:51, MitchAlsup1 wrote:
>>> On Mon, 16 Sep 2024 8:34:19 +0000, David Brown wrote:
>>>
>>>> On 15/09/2024 21:13, MitchAlsup1 wrote:
>>>>>
>>>>> 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).
>>>
>>> Sometimes you don't have a choice::
>>> x86-64 segment registers.
>>> PCIe MMI/O registers,
>>> ..
>>
>> The folks designing those register setups had a choice, and made a bad
>> choice from the viewpoint of software (whether it be C, assembly, or any
>> other language).
>>
>> It's conceivable that it was the right choice on balance, considering
>> many factors.  And it's certainly more believable that it was an
>> appropriate choice when sizes were smaller.  It is less believable that
>> there is an overwhelming need to cross a 64-bit boundary.
> 
> Several pieces of software discoverd that "bad" smaller data
> structures lead to faster execution.  Simply, smaller data structures
> lead to better utilization of caches and busses, and efect due to
> this was larger than cost of extra instructions.  So need to cross
> 64-bit boundary may be rare, but there will be cases when it is best
> choice.
> 

It is possible, but I think it is rare.

Perhaps my perception is biased from working with microcontrollers, 
where you often don't have caches and instruction speeds are not nearly 
as much faster than ram access speeds as you see in modern x86 systems.

The other thing I don't like about split bit-fields is that there is 
typically no way to do atomic updates, which can mean you need extra 
care to keep things correct.