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]
> <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.)
>
>
>