On 9/11/25 4:52 PM, Tiago Freire wrote:
> You touched another problematic point.
>
> The problem is this already exists in C, and the proposal is it
> shouldn't be incompatible. So, whatever C is doing today C++ should do
> the same.
> What C does on x86_64 right now is alignof(_BitInt(512)) = 8.
>
> If in the future Intel comes up with an extension that would allow
> arithmetic to take place in 512bit AVX registers, and would allow for
> direct operations on memory but only aligned on a 64byte boundary, then
> alignof(_BitInt(512)) would still be 8, and _BitInt(512) would be
> unable to use it because the ABI has already been defined and
> libraries using it already exist.

Sure, that is a QoI issue, not a problem for the C++ standard nor a
problem for the proposal.

I still don't see a problem.

Tom.

>
> It's just another nail.
>
>
>
> ------------------------------------------------------------------------
> *From:* Tom Honermann <tom_at_[hidden]>
> *Sent:* Thursday, September 11, 2025 9:57:35 PM
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>;
> Lénárd Szolnoki <cpp_at_[hidden]>
> *Cc:* Tiago Freire <tmiguelf_at_[hidden]>
> *Subject:* Re: [std-proposals] D3666R0 Bit-precise integers
>
> On 9/11/25 11:58 AM, Tiago Freire via Std-Proposals 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?
>
> Assuming that you are specifically referring to the AVX zmm set of
> registers, the answer is that it depends on the alignment of _BitInt(512).
>
> If the _BitInt(512) alignment is 64 bytes, then the compiler can issue
> AVX-512 instructions that require alignment (if the address of var is
> not aligned, then UB occurs). Otherwise, the compiler can issue AVX-512
> instructions that do not require alignment. In the latter case, if a
> programmer wants to optimize for best performance, then can use alignas
> as Lénárd demonstrated.
>
> Again, I don't see a problem.
>
> Tom.
>
> >
> >
> > -----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] <mailto:david.brown_at_[hidden]>>
> >> *Sent:* Friday, September 5, 2025 9:09:40 AM
> >> *To:* Tiago Freire <tmiguelf_at_[hidden]>
> <mailto:tmiguelf_at_[hidden] <mailto:tmiguelf_at_[hidden]>>; std-
> >> proposals_at_[hidden] <mailto:std-proposals_at_[hidden]
> <mailto:std-proposals_at_[hidden]>><std-
> >> proposals_at_[hidden]> <mailto: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]
> <mailto:david.brown_at_[hidden]>>, if you
> >> feel further discussions would be helpful.)
> >>
> >>
> >>
> >>
>