Vincent Lefevre vincent at vinc17.net
Mon Dec 10 15:35:27 UTC 2018

On 2018-12-10 13:51:05 +0100, Torbjorn Granlund wrote:
>   All this assuming no padding bits (I doubt they are supported),
>   which would make things even more complex.
> We sort of support the nails feature, which might be what you mean
> by padding. It is poorly maintained, and never left its status as
> experimental.

No, I meant in the sense os ISO C. For instance, one can have
a 8-byte type unsigned int (= 64 bits), with 48 value bits and
16 padding bits. Thus such an unsigned int would be between 0
and 2^48.

The only known case I'm aware of is the one from the C rationale:

  Padding bits are user-accessible in an unsigned integer type. For
  example, suppose a machine uses a pair of 16-bit shorts (each with
  its own sign bit) to make up a 32-bit int and the sign bit of the
  lower short is ignored when used in this 32-bit int. Then, as a
  32-bit signed int, there is a padding bit (in the middle of the 32
  bits) that is ignored in determining the value of the 32-bit signed
  int. But, if this 32-bit item is treated as a 32-bit unsigned int,
  then that padding bit is visible to the user’s program. The C
  committee was told that there is a machine that works this way, and
  that is one reason that padding bits were added to C99.

It seems that padding bits will not reappear in the future, even
though one could imagine nice implementation-specific uses (e.g.,
special trap values to represent the equivalent of infinity and
NaN of FP, or the use of padding bits for boxing, like what OCaml
does internally).

Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

More information about the gmp-devel mailing list