Date: Tue, 2 Sep 2025 23:16:57 +0200
On 02/09/2025 18:38, Tiago Freire wrote:
> See here's my problem:
>
>> 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.
>
>> Ultimately, this will be implementation-dependent. But it seems natural (to me) that alignment of a _BitInt should normally be that of the any standard unsigned integer type that can contain them, or uint64_t for larger _BitInt's. (That's what C23 does.)
>
> These 2 statements are contradictory. It is either one or the other and it can't be both.
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.
> The real answer is actually neither, this is actually UB. It's all UB, it always has been.
How can something that is not yet a feature of the language, have
"always" been UB?
> Since alignment is not specified converting it to anything is UB.
Alignment is not an issue when converting anything. Converting between
types is done by value. Alignment only matters for pointers.
And the alignment of different types is not UB, it is
implementation-defined behaviour.
> Maybe it works on some hardware that are tolerant with alignment, and some implementations may try to align with what you probably want to do anyways, but it's still UB.
>
_BitInt types would always be accessed via pointers that are
appropriately aligned, unless you are playing silly buggers with
converting pointer types - just like for all other types.
> You want to work with specialized registers? The best way is for the compiler to provide concrete types that satisfy both the size and alignment requirements for those registers.
If you have hardware that works best with types of a particular bit
size, why not have standardised types that are of that particular bit
size - to the best of the target implementation's abilities?
> You can't just use a _BitInt and expect it to align because it doesn't have too, and according to you own words it can't be used for larger specialized registers, that's what you and everyone wants to do but that is not what it actually does.
>
Why would you not have to have appropriate alignment for _BitInt types?
> That's why I picked that example. It's either a chunky boy or it doesn't align, the end.
>
For C23 _BitInt, _BitInt(512) will have the same alignment as uint64_t.
I would expect the same for C++ _BitInt.
> See here's my problem:
>
>> 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.
>
>> Ultimately, this will be implementation-dependent. But it seems natural (to me) that alignment of a _BitInt should normally be that of the any standard unsigned integer type that can contain them, or uint64_t for larger _BitInt's. (That's what C23 does.)
>
> These 2 statements are contradictory. It is either one or the other and it can't be both.
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.
> The real answer is actually neither, this is actually UB. It's all UB, it always has been.
How can something that is not yet a feature of the language, have
"always" been UB?
> Since alignment is not specified converting it to anything is UB.
Alignment is not an issue when converting anything. Converting between
types is done by value. Alignment only matters for pointers.
And the alignment of different types is not UB, it is
implementation-defined behaviour.
> Maybe it works on some hardware that are tolerant with alignment, and some implementations may try to align with what you probably want to do anyways, but it's still UB.
>
_BitInt types would always be accessed via pointers that are
appropriately aligned, unless you are playing silly buggers with
converting pointer types - just like for all other types.
> You want to work with specialized registers? The best way is for the compiler to provide concrete types that satisfy both the size and alignment requirements for those registers.
If you have hardware that works best with types of a particular bit
size, why not have standardised types that are of that particular bit
size - to the best of the target implementation's abilities?
> You can't just use a _BitInt and expect it to align because it doesn't have too, and according to you own words it can't be used for larger specialized registers, that's what you and everyone wants to do but that is not what it actually does.
>
Why would you not have to have appropriate alignment for _BitInt types?
> That's why I picked that example. It's either a chunky boy or it doesn't align, the end.
>
For C23 _BitInt, _BitInt(512) will have the same alignment as uint64_t.
I would expect the same for C++ _BitInt.
Received on 2025-09-02 21:17:00