Path: ...!3.eu.feeder.erje.net!feeder.erje.net!news.in-chemnitz.de!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Tue, 17 Sep 2024 13:15:36 +0300
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <20240917131536.00003a7a@yahoo.com>
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>
	<vcbi5c$3ecji$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Tue, 17 Sep 2024 12:15:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="230b2ded398db3592516a771801d7f1a";
	logging-data="3586719"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18lao7VDTbqlQFPZGJBkk7a9PaeIT5mv5Q="
Cancel-Lock: sha1:z92Ip9H6Wa4Ryguz0KGG5j20QbE=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 4738

On Tue, 17 Sep 2024 11:29:15 +0200
David Brown <david.brown@hesbynett.no> wrote:

> On 17/09/2024 03:36, Waldek Hebisch wrote:
> > David Brown <david.brown@hesbynett.no> wrote: =20
> >> On 16/09/2024 19:51, MitchAlsup1 wrote: =20
> >>> On Mon, 16 Sep 2024 8:34:19 +0000, David Brown wrote:
> >>> =20
> >>>> On 15/09/2024 21:13, MitchAlsup1 wrote: =20
> >>>>>
> >>>>> 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,...}=20
> >>>>
> >>>> 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.=C2=A0 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). =20
> >>>
> >>> Sometimes you don't have a choice::
> >>> x86-64 segment registers.
> >>> PCIe MMI/O registers,
> >>> .. =20
> >>
> >> 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. =20
> >=20
> > 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.
> >  =20
>=20
> It is possible, but I think it is rare.
>=20
> Perhaps my perception is biased from working with microcontrollers,=20
> 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.

On the other hand, with MCUs it's quite common to be limited by size of
data storage (SRAM), while size of program storage (flash) is bigger
than one will ever want. Plus, quite often, speed is of less concern.
In such [common] situation densely packed [arrays of] structures could
be desirable.

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

In the common case, on common ISAs atomic RMW update of bit field is
impossible even when the field does not cross a word boundary.

In case you mean write-only update (i.e. values of adjacent fields are
known in advance and not expected to change), what you say can be
correct or not, depending on availability of unaligned stores and on
what exactly one consider 'atomic'.