On 01/09/2025 20:47, Tiago Freire via Std-Proposals wrote:
> My gripe with _BitInt is that it is made for an abstract machine that
> has no real world analogous.
>

_BitInt /does/ have real-world analogues, which is precisely why it was
added to C (first as an extension in clang/llvm, then in C23). A major
one is for FPGAs and other custom hardware, which is seeing more and
more design work being done in higher level languages and sequential
languages (like C and C++) rather than traditional hardware design
languages (like Verilog and VHDL). 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. _BitInt is not essential for using
C or C++ for this kind of work, but it does make it clearer and neater
to work with, and it saves you from needing compiler-specific extensions.

Additionally, _BitInt has no integer promotions. This can again make it
easier to write portable, efficient and safe low-level code, by removing
one of the implementation-dependent aspects of the <stdint.h> fixed-size
integer types.

Bit-counted integer types are a natural type for bitfields - especially
in low-level and hardware-related coding.

And they can give neater and clearer code for algorithms used in
cryptography and compression.

So yes, they have real-world analogues - both in terms of modelling some
real-world hardware, and in modelling some real-world software needs.

> 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?
>

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