Do you understand that there is a difference between:
1. Aligned load
2. Aligned store
And:
1. Copy from unaligned memory to aligned memory
2. Aligned load
3. Aligned store
4. Copy from aligned memory to unaligned memory
?


From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Sebastian Wittmeier via Std-Proposals
Sent: Thursday, September 4, 2025 09:10
To: std-proposals_at_[hidden]
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]>
Subject: Re: [std-proposals] D3666R0 Bit-precise integers


A compiler may generate the suitable instructions to load from memory or store into memory. Whether it is a single load or multiple loads.



Why do different compilers (with different ABI) have to agree on alignment? Perhaps if it can be used for standard layout types?




-----Ursprüngliche Nachricht-----
Von: Tiago Freire via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Gesendet: Do 04.09.2025 08:51
Betreff: Re: [std-proposals] D3666R0 Bit-precise integers
An: Jan Schultke <janschultke_at_[hidden]<mailto:janschultke_at_[hidden]>>;
CC: Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>>; std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>;
A CPU may not be able to perform unaligned loads and stores.
That's why alignment requirements are even a thing, otherwise why would we even bother with alignment?

-----Original Message-----
From: Jan Schultke <janschultke_at_[hidden]<mailto:janschultke_at_[hidden]>>
Sent: Thursday, September 4, 2025 08:43
To: Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>>
Cc: std-proposals_at_[hidden]rg<mailto:std-proposals_at_[hidden]>
Subject: Re: [std-proposals] D3666R0 Bit-precise integers

> > What is that even supposed to mean?!
>
> It's a term used to describe a practice that shouldn't work but it does in practice because of an unanticipated obscure feature and nobody understand why.

You're using the term to describe basic compiler mechanisms like register allocation and loading/storing from memory though, so I'm not seeing how this makes any sense.

It's not that "unanticipated and obscure" that when you do __builtin_compute_sha or something, it would load a _BitInt(384) from memory into a register to perform that special operation. It's not any different from loading an int from four bytes of memory into eax in order to perform addition.

It's also not "unanticipated and obscure" that when _BitInt(384) is the return type of a function, that the result is passed via the SHA acceleration register or via the stack or something, depending on the ABI. It's the same principle as passing an int via eax and passing larger types like structs on the stack (or having an extra result parameter that tells you the address of the returned object).
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Even