It was Intel, which originally brought in the 8-byte assignment for wide _BitInt types.   -----Ursprüngliche Nachricht----- Von:Lénárd Szolnoki via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 11.09.2025 21:01 Betreff:Re: [std-proposals] D3666R0 Bit-precise integers An:Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_[hidden]; CC:Lénárd Szolnoki <cpp_at_[hidden]>; On 11/09/2025 16:58, Tiago Freire wrote: > Look at this signature: > > void func(_BitInt(512)& var); > > true or false, if this function uses var in a way that requires being loaded into zmm does it require realignment? False, it doesn't, it can just use unaligned load, which should be much faster than realigning the object in memory then using an aligned load in all cases. If you don't want it to be a performance penalty, you can call it with a reference to a suitably aligned object, which you can arrange with alignas. AFAIK unaligned load instructions are not any slower on recent CPUs when given a memory address that happens to be suitably aligned. Regardless, if you want to give the function freedom to use an unaligned load instruction then you still have several options: * Document that you expect a suitably aligned object, use std::assume_aligned in the implementation. Use with caution. * Use my suggested `MyInt512` in the signature, and possibly throughout the rest of the program. * Implement and use something like `aligned_reference<_BitInt(512), 64>` or `aligned_ptr<_BitInt(512), 64>` and use them in your interface as documentation, preferrably requiring an explicit construction from raw pointer/reference. These should call assume_aligned for you wherever appropriate. * Use mdspan with aligned_accessor Accessor policy, which does the same. Some core sticking points: * Yes, types have an alignment property, which might not be the best for each use. You can't please everybody. I'm sure I would be surprised to find 56 bytes of padding between a pointer and a _BitInt(512) member in a class. * Regardless, you can allocate objects at your desired stricter alignment then what their type's associated alignment is. * On the other side of function interfaces you have several options that tells the compiler that the object is aligned to your desired alignment. > > > -----Original Message----- > From: Lénárd Szolnoki <cpp_at_[hidden]> > Sent: Thursday, September 11, 2025 17:28 > To: std-proposals_at_[hidden]; Tiago Freire <tmiguelf_at_[hidden]> > Subject: Re: [std-proposals] D3666R0 Bit-precise integers > > > > On 11/09/2025 16:13, Tiago Freire via Std-Proposals wrote: >> I was not particularly interested in the term values as per “C++ standard per definition” >> of the abstract machine, but either or not you could physically get a computer to do it. >> >> Can you use something like _BitInt(512) to write algorithm, have a >> compiler not respect alignment requirements expected to load a zmm >> register, and have a guarantee that the compiler would spit out machine code that that would be able to run and perform as expected? > > struct alignas(64) MyInt512 { >     _BitInt(512); > }; > > Now you have a type that is aligned. Add operators/conversions to taste. > > If you don't want a wrapper, you can also just align the data, wherever you have that, and use assume_aligned elsewhere. You can have safe wrappers around this as well. We also got aligned_accessor into the standard for mdspan. > >> >> The answer is no, unless you’re a willing to also issue realignment >> instruction as required every time you need to load or store. >> >> Talking about the abstract machine is a red herring, abstract machines >> don’t run code, physical computers do. Ands it’s irrelevant that you >> can represent something in a programming language if the machine is physically unable to do something (i.e. >> unimplementable). >> >> I can define that a uint64_t has an alignment of 3, and be purely >> consistent as far as the language goes. You just wouldn’t be able to >> compile that (or if you do it wouldn’t run on your machine without realignment). >> >> Am I incorrect on this? >> >> *From:*Tom Honermann <tom_at_[hidden]> >> *Sent:* Thursday, September 11, 2025 16:18 >> *To:* std-proposals_at_[hidden]; David Brown >> <david.brown_at_[hidden]> >> *Cc:* Tiago Freire <tmiguelf_at_[hidden]> >> *Subject:* Re: [std-proposals] D3666R0 Bit-precise integers >> >> It has taken me a while to catch up on all of the recent emails. >> >> Tiago, this is at least the third time that I've seen you passionately >> arguing for a perspective that is objectively incorrect from the >> perspective of the C++ standard. David provided clear and unambiguous >> references to the C and C++ standards to justify his >> (correct) view and interpretation of values and objects. You have a >> fine understanding of how some machines work. It is clear to me that >> you lack some understanding of how the C and C++ languages define an >> abstract language that can be mapped to a wide variety of hardware (including the various mental model compilers that reside in each of our minds). >> I suggest a little humility and advise you to take some time to study >> the C and C++ standards more thoroughly, particularly with regard to terminology. >> >> Values do not have alignment. They do not even have representation (in >> the C and C++ standards). They are platonic abstractions. Rvalues correspond to a value. >> >> Values may be held in objects. Objects have value representation and >> alignment defined by their type. Objects reside in addressable storage. Lvalues refer to an object. >> >> A psABI defines alignment for types appropriate for the applicable >> machine(s). Those specifications assign alignment and representation >> appropriate for the manipulation of objects and operations on values. >> >> Tom. >> >> On 9/5/25 5:34 AM, Tiago Freire via Std-Proposals wrote: >> >>      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]> <mailto:david.brown_at_[hidden]> >>      *Sent:* Friday, September 5, 2025 9:09:40 AM >>      *To:* Tiago Freire <tmiguelf_at_[hidden]> <mailto:tmiguelf_at_[hidden]>; std- >>      proposals_at_[hidden] <mailto:std-proposals_at_[hidden]><std- >>      proposals_at_[hidden]> <mailto: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] >>      <mailto: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