On Fri, Sep 5, 2025 at 11:29 AM Tiago Freire via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> So why are we even bothering with alignment then of any type? We can just issue multiple instructions to pre-align anything and then again to put the data back where they belong.
> Why don't we just do that?

The situation you hypothesized was one where there *is no alignment*
which would allow a 384-bit integer to be able to be loaded into/read
from a specialized SHA register in one instruction. If the hardware
doesn't allow for a single instruction read/write regardless of
alignment, then you have to do it in multiple reads/writes.

If there is an alignment which would allow that on that platform, then
the compiler is free to give `_BitInt(384)` that alignment.

Basically, the implementation has the power to make reads and writes
as fast as the hardware allows. There is nothing about the
specification of `_BitInt` that makes an implementation slower than
the equivalent assembly code.

> ________________________________
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
> Sent: Friday, September 5, 2025 4:01:52 PM
> To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> Cc: Sebastian Wittmeier <wittmeier_at_[hidden]>
> Subject: Re: [std-proposals] D3666R0 Bit-precise integers
>
> The implementation can advantageously use special registers on FPGAs or specialized computation units/accelerators, it can be used on modern PCs with less than 64 bytes alignment, independent of the cache architecture. Perhaps some alignment can help with performance, but to have a large alignment (normally) is not necessary.
>
>
>
> The horse is alive and kicking (even a capriole).
>
>
> -----Ursprüngliche Nachricht-----
> Von: Tiago Freire <tmiguelf_at_[hidden]>
> Gesendet: Fr 05.09.2025 15:22
> Betreff: Re: [std-proposals] D3666R0 Bit-precise integers
> An: std-proposals_at_[hidden];
> CC: Sebastian Wittmeier <wittmeier_at_[hidden]>;
> The argument was that it could be used to represent specialized registers, it can't. Why are we still beating this dead horse?
> ________________________________
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
> Sent: Friday, September 5, 2025 1:05:01 PM
> To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> Cc: Sebastian Wittmeier <wittmeier_at_[hidden]>
> Subject: Re: [std-proposals] D3666R0 Bit-precise integers
>
>
> Nobody (?) said it has to be done with a single store/load.
>
> 384 bits are 3x16 bytes.
>
> -----Ursprüngliche Nachricht-----
> Von: Tiago Freire via Std-Proposals <std-proposals_at_[hidden]>
> Gesendet: Fr 05.09.2025 11:34
> Betreff: Re: [std-proposals] D3666R0 Bit-precise integers
> An: David Brown <david.brown_at_[hidden]>; std-proposals_at_[hidden];
> CC: Tiago Freire <tmiguelf_at_[hidden]>;
> And yet you don't understand that in some CPUs store/loads cannot strut across cache lines.
> This is something that a CPU may not have the circuitry to physically do.
>
>
> ________________________________
> From: David Brown <david.brown_at_[hidden]>
> Sent: Friday, September 5, 2025 9:09:40 AM
> To: Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> Subject: Re: [std-proposals] D3666R0 Bit-precise integers
>
> On 04/09/2025 17:18, Tiago Freire wrote:
> > I've not made a mistake. I've not mixed up bits and bytes. Please show
> > me a quote where that happened?
>
> In a post on 04.09.2025 08:27 you wrote in a reply to Jan Schultke "I do
> mean bytes, not bits". I took that to mean you saw you had been unclear
> or mixed up about bytes and bits. After all, you had been talking about
> the alignments of something you wrote as "64Byte" - it was not at all
> clear if you were talking about the alignment of a 64-bit type (which is
> what everyone else was talking about, including the C23 standards), or
> some kind of 64 /byte/ alignment (which would clearly be absurd at the
> level of programming languages and/or ABIs).
>
> I apologise if I misinterpreted you there.
>
> >
> > I don't know why you are trying to gaslight.
>
> I am not doing that at all. I am merely frustrated in this conversation.
>
> >
> > If you don't know how CPU's work just say you don't know how it works!
>
> I have studied the architecture of perhaps 20 or more processor designs,
> from 4-bit to 64-bit and a few odd ones in-between, and written serious
> assembly-level programs on most of them. The field of processor
> architecture is vast, and there is a vast amount I don't know, but I
> /do/ know how they work.
>
> I also - and this is the key point - understand the difference between a
> high-level programming language and its specification, and particular
> implementations that might be used with it. I'm sure you have at least
> a reasonable understanding of how cpus work too - but I am very sure you
> don't understand the separation of programming language design and
> implementation. You have to understand that distinction if you are
> going to understand why _BitInt can be a useful (albeit fairly niche)
> addition to C++, and why it will work both on "normal" processors and
> specialist hardware. It will also help you understand why many of your
> ideas are at odds with the other posters here who all want standard C++
> to be improved as a programming language, rather than become some weird
> hybrid assembly for a few chosen processors and your favourite assembly
> instructions of the day. I sincerely hope you can understand this
> distinction, and we can get back to discussions about C++ here.
>
> It would probably be good if you didn't reply, at least not to this
> mailing list. (My email address is david.brown_at_[hidden], if you
> feel further discussions would be helpful.)
>
> -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals