So you say _BitInt(384) has an ABI, you refer to Clang: _BitInt(384) has an alignment of 8 bytes. And you say, extended registers (384 bits) for certain PC CPUs cannot easily store/load with that alignment? Can you please name the CPU and the register you are referencing, which would profit from _BitInt(384) support, but needs different alignment properties?   -----Ursprüngliche Nachricht----- Von:Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 05.09.2025 19:03 Betreff:Re: [std-proposals] D3666R0 Bit-precise integers An:std-proposals_at_[hidden]; CC:Tiago Freire <tmiguelf_at_[hidden]>; This is the C++ standard mailing list, not your microcontroller implementation mailing list.   Decisions affect everyone not just FPGAs.   extended registers are a standard thing on most CPUs now a days, it's not like this is some hypothetical or anything.   And even for your microcontroller there is absolutely no reason why they would give you _BitInt- whatever to access specialized registers as opposed to giving specialized concrete types. Considering also that BitInt is to implement integer arithmetic, and you can't do general arithmetic with a sha register, so why even bother to do that instead of... you know... be optimized to use your arithmetic unit.   This idea that _BitInt if available would allow you to use exotic registers is pure fantasy.   -------------------------------- From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Sent: Friday, September 5, 2025 6:40:57 PM To: std-proposals_at_[hidden] <std-proposals_at_[hidden]> Cc: Jason McKesson <jmckesson_at_[hidden]> Subject: Re: [std-proposals] D3666R0 Bit-precise integers On Fri, Sep 5, 2025 at 12:25 PM Tiago Freire <tmiguelf_at_[hidden]> wrote: > > > If there is an alignment which would allow that on that platform, then > the compiler is free to give `_BitInt(384)` that alignment. > > Says who? > It already has an ABI, it already is not true. That was the whole point of the discussion. I understood that we were discussing some microcontroller architecture with direct support for SHA registers and processing. Something that's attached to the CPU and thus is effectively a part of the platform, or is just a novel processor entirely. Such a platform would have its own ABI, and it therefore has the freedom to assign the alignment of `_BitInt(384)` whatever it feels is most efficient. It would not be expected to be ABI-compatible with other architectures. That is, we're not talking about slapping some SHA-accelerator card into your average PC. > ________________________________ > From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> > Sent: Friday, September 5, 2025 6:16:25 PM > To: std-proposals_at_[hidden] <std-proposals_at_[hidden]> > Cc: Jason McKesson <jmckesson_at_[hidden]> > Subject: Re: [std-proposals] D3666R0 Bit-precise integers > > 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 > -- > 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 -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals