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_googlemail.com>
Sent: Thursday, September 4, 2025 08:43
To: Tiago Freire <tmiguelf_at_[hidden]>
Cc: std-proposals_at_lists.isocpp.org
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).