Date: Sat, 6 Sep 2025 06:04:25 +0200
> Sure, but the need of FPGAs are one of the driving justifications for
> `_BitInt`. Like, it's in the very first paper for the C standard
> discussing it:
>
> https://open-std.org/JTC1/SC22/WG14/www/docs/n2763%2epdf
It's also worth pointing out that while we're talking about
_BitInt(384) and _BitInt(512) and whatnot, the much bigger problem
lies with smaller _BitInt sizes. Even if the implementation provided
some custom type for a 9-bit register, the C language literally
doesn't allow you to do proper 9-bit arithmetic because even extended
integers are subject to promotion, so you'd do arithmetic on int
instead.
Integer promotion in general is such a devastating design blunder that
it's worth having _BitInt just to clean up that mess. It's why
multiplying two UNSIGNED shorts can have undefined behavior due to
SIGNED integer overflow.
> `_BitInt`. Like, it's in the very first paper for the C standard
> discussing it:
>
> https://open-std.org/JTC1/SC22/WG14/www/docs/n2763%2epdf
It's also worth pointing out that while we're talking about
_BitInt(384) and _BitInt(512) and whatnot, the much bigger problem
lies with smaller _BitInt sizes. Even if the implementation provided
some custom type for a 9-bit register, the C language literally
doesn't allow you to do proper 9-bit arithmetic because even extended
integers are subject to promotion, so you'd do arithmetic on int
instead.
Integer promotion in general is such a devastating design blunder that
it's worth having _BitInt just to clean up that mess. It's why
multiplying two UNSIGNED shorts can have undefined behavior due to
SIGNED integer overflow.
Received on 2025-09-06 04:04:38