Path: ...!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: Mon, 16 Sep 2024 11:27:15 +0200
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <vc8tlj$2od19$3@dont-email.me>
References: <vaqgtl$3526$1@dont-email.me> <86r09ulqyp.fsf@linuxsc.com>
 <2024Sep8.173639@mips.complang.tuwien.ac.at>
 <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>
 <2024Sep15.194612@mips.complang.tuwien.ac.at> <vc8m5k$2nf2l$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 16 Sep 2024 11:27:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d1583d3c65366d20e8e7bb3dd5deb61e";
	logging-data="2896937"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX185k+43BvAChnNb0ZilwBs0/lO5O12WhCE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:qgMUK0kp188bbJhJz2eb/3rdHbA=
Content-Language: en-GB
In-Reply-To: <vc8m5k$2nf2l$1@dont-email.me>
Bytes: 4239

On 16/09/2024 09:18, BGB wrote:
> On 9/15/2024 12:46 PM, Anton Ertl wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>>> Padding is another thing that should be Implementation Defined.
>>
>> It is.  It's defined in the ABI, so when the compiler documents to
>> follow some ABI, you automatically get that ABI's structure layout.
>> And if a compiler does not follow an ABI, it is practically useless.
>>
> 
> Though, there also isn't a whole lot of freedom of choice here regarding 
> layout.
> 
> If member ordering or padding differs from typical expectations, then 
> any code which serializes structures to files is liable to break, and 
> this practice isn't particularly uncommon.
> 

Your expectations here should match up with the ABI - otherwise things 
are going to go wrong pretty quickly.  But I think most ABIs will have 
fairly sensible choices for padding and alignments.

> Say, typical pattern:
> Members are organized in the same order they appear in the source code;

That is required by the C standards.  (A compiler can re-arrange the 
order if that does not affect any observable behaviour.  gcc used to 
have an optimisation option that allowed it to re-arrange struct 
ordering when it was safe to do so, but it was removed as it was rarely 
used and a serious PITA to support with LTO.)

> If the current position is not a multiple of the member's alignment, it 
> is padded to an offset that is a multiple of the member's alignment;

That is a requirement in the C standards.

The only implementation-defined option is whether or not there is 
/extra/ padding - and I have never seen that in practice.  (And there 
are more implementation-defined options for bit-fields.)

> For primitive types, the alignment is equal to the size, which is also a 
> power of 2;

That is the norm, up to the maximum appropriate alignment for the 
architecture.  A 16-bit cpu has nothing to gain by making 32-bit types 
32-bit aligned.

> If needed, the total size of the struct is padded to a multiple of the 
> largest alignment of the struct members.

That is required by the C standards.

> 
> 
> 
> For C++ classes, it is more chaotic (and more compiler dependent), but:

Not really, no.  Apart from a few hidden bits such as pointers to handle 
virtual methods and virtual inheritance, the data fields are ordered, 
padded and aligned just like in C structs.  And these hidden pointers 
follow the same rules as any other pointer.

The only other special bit is empty base class optimisation, and that's 
pretty simple too.