Date: Wed, 3 Sep 2025 08:26:52 +0200
> > Well, you can only get the exact sizes on platforms that support those exact sizes. On other platforms, the _BitInt types need to be contained in something larger if they are cannot be provided directly. So a _BitInt(9) is likely to need an FPGA or special hardware for its size to be exactly 9 bits. But they can be implemented in an obvious way on other platforms, just with padding bits. Alignment will be implementation dependent, just as it is for all other types.
>
> What says who? What guarantees your compiler when you specify _BitInt(9) to go "nah he wants a specialized 9bit FPGA register" instead of just giving you a 16bit register with 7 unused bits?
Nobody's claiming that merely using _BitInt(9) expresses the intent
that you want this to be some FPGA-specific type in your code. Adding
a static_assert that _BitInt(9) has no padding bits does that.
> > How can something that is not yet a feature of the language, have "always" been UB?
>
> It already exists in C. That the argument, whatever C is doing C++ will adopt for interoperability, there is no room for alternative behavior here.
Yeah, P3666 is a C compatibility proposal first and foremost. Unless
there is a really compelling reason to deviate from the C behavior,
that won't find consensus. At least that's the impression I'm getting
from feedback on P3639 (_BitInt debate) and other C compatibility
proposals I've cooked up.
> That's why when you say things like "When you are dealing with hardware with 9-bit integers, or an SHA accelerator with 384-bit registers, you want types that have the exact size."
> And I ask "How does _BitInt(384) operate on SHA accelerator with 384-bit registers when it's not aligned?", and now you are telling me "It doesn't! We just copy it over to a type that does."...what are we talking about?
Alignment is only relevant to the ABI and to loading and storing
objects in memory. Registers such as a 384-bit register are just a
bunch of flip-flop circuitry. Such a SHA accelerator may as well have
1-byte alignment _BitInt(384).
In any case, alignment is just something that's up to the platform
ABI, and may be somewhat constrained by what CPU instructions let you
do.
>
> What says who? What guarantees your compiler when you specify _BitInt(9) to go "nah he wants a specialized 9bit FPGA register" instead of just giving you a 16bit register with 7 unused bits?
Nobody's claiming that merely using _BitInt(9) expresses the intent
that you want this to be some FPGA-specific type in your code. Adding
a static_assert that _BitInt(9) has no padding bits does that.
> > How can something that is not yet a feature of the language, have "always" been UB?
>
> It already exists in C. That the argument, whatever C is doing C++ will adopt for interoperability, there is no room for alternative behavior here.
Yeah, P3666 is a C compatibility proposal first and foremost. Unless
there is a really compelling reason to deviate from the C behavior,
that won't find consensus. At least that's the impression I'm getting
from feedback on P3639 (_BitInt debate) and other C compatibility
proposals I've cooked up.
> That's why when you say things like "When you are dealing with hardware with 9-bit integers, or an SHA accelerator with 384-bit registers, you want types that have the exact size."
> And I ask "How does _BitInt(384) operate on SHA accelerator with 384-bit registers when it's not aligned?", and now you are telling me "It doesn't! We just copy it over to a type that does."...what are we talking about?
Alignment is only relevant to the ABI and to loading and storing
objects in memory. Registers such as a 384-bit register are just a
bunch of flip-flop circuitry. Such a SHA accelerator may as well have
1-byte alignment _BitInt(384).
In any case, alignment is just something that's up to the platform
ABI, and may be somewhat constrained by what CPU instructions let you
do.
Received on 2025-09-03 06:27:07