Date: Mon, 1 Sep 2025 20:58:47 +0200
> My gripe with _BitInt is that it is made for an abstract machine that has no real world analogous.
Seeing that _BitInt is now part of the C platform ABI and that there's
a real need to interface with that, objecting to the idea as a whole
is all a bit late. That ship sailed with C23.
> ints don't have just size but also alignment properties.
> what should the alignment of _BitInt(512) should be?
> Should it align to the cache line? or should it align with the requirements for the largest implementable operand to save on space?
One possible approach can be found in
https://gitlab.com/x86-psABIs/x86-64-ABI, which is to make _BitInt
like a 64-bit integer in the ABI, aligned to 64 bits, and for any
_BitInt of width greater than 64, it is treated like a struct with
64-bit integers inside.
I don't see what makes _BitInt special. It's just another type defined
in the abstract machine, and it's the job of the platform ABI to
define how that's passed around and what the alignment should be.
_BitInt(1000000) and int are essentially the same in this regard.
Seeing that _BitInt is now part of the C platform ABI and that there's
a real need to interface with that, objecting to the idea as a whole
is all a bit late. That ship sailed with C23.
> ints don't have just size but also alignment properties.
> what should the alignment of _BitInt(512) should be?
> Should it align to the cache line? or should it align with the requirements for the largest implementable operand to save on space?
One possible approach can be found in
https://gitlab.com/x86-psABIs/x86-64-ABI, which is to make _BitInt
like a 64-bit integer in the ABI, aligned to 64 bits, and for any
_BitInt of width greater than 64, it is treated like a struct with
64-bit integers inside.
I don't see what makes _BitInt special. It's just another type defined
in the abstract machine, and it's the job of the platform ABI to
define how that's passed around and what the alignment should be.
_BitInt(1000000) and int are essentially the same in this regard.
Received on 2025-09-01 18:59:02