Date: Thu, 11 Sep 2025 15:56:34 -0400
On 9/11/25 2:04 PM, Tiago Freire via Std-Proposals wrote:
>
> > Why would a compiler not respect the psABI alignment requirements
> specified for the _Bitint(512) type? What you described would be UB.
>
> Because it already has an ABI in C and in common architectures the
> alignment is 8bytes while 512bit sized registers are at least 16bytes
> alignment to load, and require 64bytes for optimal performance.
What is common for some architectures is irrelevant for any particular
architecture. Alignment is an implementation-defined property of almost
all types.
Why would the alignment requirement be different for C and C++?
I think the concern you are expressing here is a QoI one. Yes, a poor
ABI choice could have ramifications later. That is not a problem the C
or C++ standards can address. If your implementor provides a poor QoI
implementation, talk to them, find another implementation, or work
around it.
>
> That what I described would be UB is the point, it is UB, hence should
> not be used for this purpose.
>
> > If you have an architecture that has some specialized register
> suitable for manipulation of, say, a value of _Bitint(512) type, and
> load/store instructions that require some particular alignment, and a
> compiler that takes advantage of those features, then the alignment of
> _Bitint(512) will be specified by the psABI to meet the requirements
> of those load/store instructions. There is no problem here.
>
> Which could be true, while platforms such as arm or x86_64 do have
> 512bit registers, they don't do 512bit arithmetic, so the registers
> that _Bitint(512) would use are 64bit only.
Sure, they might not support 512 bit arithmetic using those registers
today, but future revisions might. It might also be possible to perform
some 512 bit arithmetic operations using other instructions, so the
conclusion that only 64-bit registers would be used is not assured.
>
> Which was my argument _Bitint(512) not the same as "uses 512 bit
> registers" which had been implied.
I agree they are not the same. I don't recall such an implication.
Tom.
>
> Not to mention the dimension that similarly uint32_t is not made to
> represent floating point registers even if they do satisfy size and
> alignment requirements because an fpu is a completely different unit.
>
>
> ------------------------------------------------------------------------
> *From:* Tom Honermann <tom_at_[hidden]>
> *Sent:* Thursday, September 11, 2025 6:48:43 PM
> *To:* Tiago Freire <tmiguelf_at_[hidden]>;
> std-proposals_at_[hidden] <std-proposals_at_[hidden]>; David
> Brown <david.brown_at_[hidden]>
> *Subject:* Re: [std-proposals] D3666R0 Bit-precise integers
>
> On 9/11/25 11:13 AM, Tiago Freire 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?
>
> You have a misunderstanding that lead you to ask that question.
>
> Why would a compiler not respect the psABI alignment requirements
> specified for the _Bitint(512) type? What you described would be UB.
>
> The answer is no, unless you’re a willing to also issue
> realignment instruction as required every time you need to load or
> store.
>
> That assumes that an object of _Bitint(512) type is stored at a
> misaligned address. If indeed it was, then loading or storing to that
> address would be UB.
>
> 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).
>
> There is nothing unimplementable about the _Bitint family of types.
> They have been implemented for multiple architectures in multiple
> compilers for bit lengths well above 512.
>
> 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).
>
> No one would choose an alignment of 3 for a uint64_t on any modern
> computer, so that example isn't relevant.
>
> Am I incorrect on this?
>
> In general on this subject, yes.
>
> If you have an architecture that has some specialized register
> suitable for manipulation of, say, a value of _Bitint(512) type, and
> load/store instructions that require some particular alignment, and a
> compiler that takes advantage of those features, then the alignment of
> _Bitint(512) will be specified by the psABI to meet the requirements
> of those load/store instructions. There is no problem here.
>
> Tom.
>
> *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]__<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]_, if you
> feel further discussions would be helpful.)
>
>
>
>
>
>
> > Why would a compiler not respect the psABI alignment requirements
> specified for the _Bitint(512) type? What you described would be UB.
>
> Because it already has an ABI in C and in common architectures the
> alignment is 8bytes while 512bit sized registers are at least 16bytes
> alignment to load, and require 64bytes for optimal performance.
What is common for some architectures is irrelevant for any particular
architecture. Alignment is an implementation-defined property of almost
all types.
Why would the alignment requirement be different for C and C++?
I think the concern you are expressing here is a QoI one. Yes, a poor
ABI choice could have ramifications later. That is not a problem the C
or C++ standards can address. If your implementor provides a poor QoI
implementation, talk to them, find another implementation, or work
around it.
>
> That what I described would be UB is the point, it is UB, hence should
> not be used for this purpose.
>
> > If you have an architecture that has some specialized register
> suitable for manipulation of, say, a value of _Bitint(512) type, and
> load/store instructions that require some particular alignment, and a
> compiler that takes advantage of those features, then the alignment of
> _Bitint(512) will be specified by the psABI to meet the requirements
> of those load/store instructions. There is no problem here.
>
> Which could be true, while platforms such as arm or x86_64 do have
> 512bit registers, they don't do 512bit arithmetic, so the registers
> that _Bitint(512) would use are 64bit only.
Sure, they might not support 512 bit arithmetic using those registers
today, but future revisions might. It might also be possible to perform
some 512 bit arithmetic operations using other instructions, so the
conclusion that only 64-bit registers would be used is not assured.
>
> Which was my argument _Bitint(512) not the same as "uses 512 bit
> registers" which had been implied.
I agree they are not the same. I don't recall such an implication.
Tom.
>
> Not to mention the dimension that similarly uint32_t is not made to
> represent floating point registers even if they do satisfy size and
> alignment requirements because an fpu is a completely different unit.
>
>
> ------------------------------------------------------------------------
> *From:* Tom Honermann <tom_at_[hidden]>
> *Sent:* Thursday, September 11, 2025 6:48:43 PM
> *To:* Tiago Freire <tmiguelf_at_[hidden]>;
> std-proposals_at_[hidden] <std-proposals_at_[hidden]>; David
> Brown <david.brown_at_[hidden]>
> *Subject:* Re: [std-proposals] D3666R0 Bit-precise integers
>
> On 9/11/25 11:13 AM, Tiago Freire 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?
>
> You have a misunderstanding that lead you to ask that question.
>
> Why would a compiler not respect the psABI alignment requirements
> specified for the _Bitint(512) type? What you described would be UB.
>
> The answer is no, unless you’re a willing to also issue
> realignment instruction as required every time you need to load or
> store.
>
> That assumes that an object of _Bitint(512) type is stored at a
> misaligned address. If indeed it was, then loading or storing to that
> address would be UB.
>
> 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).
>
> There is nothing unimplementable about the _Bitint family of types.
> They have been implemented for multiple architectures in multiple
> compilers for bit lengths well above 512.
>
> 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).
>
> No one would choose an alignment of 3 for a uint64_t on any modern
> computer, so that example isn't relevant.
>
> Am I incorrect on this?
>
> In general on this subject, yes.
>
> If you have an architecture that has some specialized register
> suitable for manipulation of, say, a value of _Bitint(512) type, and
> load/store instructions that require some particular alignment, and a
> compiler that takes advantage of those features, then the alignment of
> _Bitint(512) will be specified by the psABI to meet the requirements
> of those load/store instructions. There is no problem here.
>
> Tom.
>
> *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]__<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]_, if you
> feel further discussions would be helpful.)
>
>
>
>
>
Received on 2025-09-11 19:56:39