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