On 11/02/2024 01:57, Chris Gary via Std-Proposals wrote:
> IMO, fixed-width multiple precision support for any reasonable bit width
> ought to be provided automatically, if not specified as an option
> (essentially, at least bitfields that are "as native as possible"). It
> should be able to work as the underlying type of an enum (like a "wide
> bitmask enum"), so not just another treatment of std::bitset.
>
> The proposal might be better refined by being a bit more specific with
> something along the lines of "int_fast128_t".
>
> That way, if there isn't a "fast" version that fits in a register (or
> has a corresponding subset of instructions), a warning would be emitted.
> Otherwise, the code can express a more relaxed width requirement just
> using "int_least128_t", allowing an emulation without warning.
>

That's not what the "fast" variants are for. "int_fastN_t" is the type
that has at least N bits and is faster (for general use in local
variables and arithmetic) than any smaller size. Thus on many 64-bit
processors, "int_fast32_t" and "int_fast16_t" are both 64-bit types.

Unless a processor had 256-bit (or larger) registers that had faster
operations than you could do with 128-bit types, you would expect
"int_fast128_t", "int_least128_t" and "int128_t" to be aliases.

> That said, I haven't seen an implementation that provides the "least" or
> "fast" variations as anything but aliases.
>