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