Deutsch   English   Français   Italiano  
<vcbiov$3ecji$3@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!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:39:43 +0200
Organization: A noiseless patient Spider
Lines: 136
Message-ID: <vcbiov$3ecji$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>
 <vc8tlj$2od19$3@dont-email.me> <vca209$319ci$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 17 Sep 2024 11:39:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3e52a47a8c62d553adb0a23714e2b020";
	logging-data="3617394"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+8vObrPqo/1GLu13YgRNzghLkNEEPrc8s="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:VYv87oPjgdP9H+6RTFCPxJHURNs=
Content-Language: en-GB
In-Reply-To: <vca209$319ci$1@dont-email.me>
Bytes: 7027

On 16/09/2024 21:46, BGB wrote:
> On 9/16/2024 4:27 AM, David Brown wrote:
>> 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.
>>
> 
> Yeah. It is "almost fixed", as there are a lot of programs that are 
> liable to break if these assumptions differ.
> 
> 
>>> 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.)
>>
> 
> OK.
> 
> 
>>> 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.)
>>
> 
> Extra padding seems like it wouldn't have much benefit.

No, generally not - which is why it would be a really strange 
implementation if it had extra padding.  It's possible that extra 
padding at the end of a struct could lead to more efficient array access 
by aligning to cache line sizes, but I think such things are better left 
to the programmer (possibly with the aid of compiler extensions) rather 
than attempting to specify them in the ABI.

> 
> Albeit, types like _Bool in my implementation are padded to a full byte 
> (it is treated as an "unsigned char" that is assumed to always hold 
> either 0 or 1).

That's the usual way to handle them.

> 
> 
>>> 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.
>>
> 
> This comes up as an issue in some Windows file formats, where one can't 
> just naively use a struct with 32-bit fields because some 32-bit members 
> only have 16-bit alignment.

Ah, the joys of using ancient formats with new systems!

My comment above was in reference to data remaining on the system, 
rather than moving off-system.

If I am making a format that is accessible externally - a file format, a 
network packet, etc., - I generally make sure all types are "naturally" 
aligned up to at least 8-byte types, even if the processor's maximum 
useful alignment is much smaller.

> 
>>> 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.
>>
> 
> For simple cases, they may match up, like a POD class may look just like 
> an equivalent struct, or single-inheritance classes with virtual methods 
> like a struct with a vtable, etc... But in more complex cases there may 
> be compiler differences (along with differences in things like name 
> mangling, etc).

I've never seen or header of a case where there there is anything 
unexpected here.

Sure, different C++ implementations or ABIs might have different details 
around these hidden pointers and the way they organise their vtables. 
But they are still hidden /pointers/, and these are aligned and padded 
like any other pointer.  Even if the hidden data contained a bunch of 
extra bits, flags, etc., to handle complicated inheritance setups, these 
would still be padded and aligned like any other structs with bits, 
flags, etc.

> 
> Though, unlike with structs, programs seem less inclined to rely on the 
> memory layout specifics of class instances.
> 

Of course they shouldn't be relying on such details!