[Trying again with a corrected E-mail address.]
What does FreeBSD support of the the possible implementation-defined aspects
for signed-integral value representations for C? C++? I ask because of 1's
complement and signed magnitude as reported on below. . .
[I'm not covering signed conversion to less precision in the below wording.]
[First a note: conversion vs. promotion
Promotions and conversions do not have equivalent rules if I remember right,
which can make the distinction important.
0 is of type int already and does not get promoted before the value is used by
~.
~0 is also of type int and is only later subject to possible conversion, not
promotion.
(As worded this presumes any "negative zero" that might result is not a trap
representation. See below.)
]
As I understand the modern rules from reading the C11 and C99 standards:
One's complement:
If "negative zero" is a trap representation then ~0 is undefined. (Also true
for &, |, ^, <<, and >> use with operands that would otherwise produce such a
trap representation.)
Otherwise ~0 is represented as -0 ("negative zero"). That -0 compares as -0 ==
0 and the like. "Sign extension" (conversion) of signed integral types to
no-less precision (still signed) is value preserving when no trap
representation is involved, so the overall result is then some value
representation of zero: possibly "negative zero" but alternately just zero: "if
the value can be represented by the new type, it is unchanged". (The
mathematical-value is unchanged, not necessarily the representation.)
Later conversion to an unsigned integral type would not convert to a non-zero
value: "if the value can be represented by the new type, it is unchanged".
(That is a mathematical-value preserving statement, not a representation
statement.) So in this context the unsigned result has the zero
value-representation for its precision even if the conversion starts with a
"negative zero".
signed magnitude:
signed magnitude ~0 has value representation all-ones with value -INT_MAX.
"Sign extension" (conversion) of signed integral types to no-less precision
(still signed) is value preserving when no trap representation is involved.
All-ones would not be value preserving for greater precision. Instead zeros
fill the "new" magnitude value-representation bits and the sign bit and the old
"magnitude bits" are preserved.
Later conversion to an unsigned integral value of an unsigned integral type
with, say, IVMAX as its maximum value then (effectively) mathematically adds
the mathematical value (IVMAX+1) to bring the signed value into into the range
of the unsigned integral type. So mathematically: (-INT_MAX)+(IVMAX+1) = IVMAX
- (INT_MAX-1).
Two's complement:
I'll not cover this (common and familiar).
C++11's fit with the above:
There are notes in C++11 about "if the underlying type as padding bits, trap
bits, or alternate representations of the same value" (such as for
compare-and-exchange). So the concepts are involved.
C++11 allows 2's complement, 1's complement, and signed magnitude as examples.
But its wording allows more: "integral types shall define values by use of a
pure binary numeration system" (with a foot note giving more detail).
For conversions: "If the destination type is unsigned, the resulting value is
the least unsigned integer congruent to the source integer" (modulo
2**precision). (I'm using ** for "raised to the power".) Also: "If the
destination type is signed, the value is unchanged if it can be represented in
the destination type (and bit-field width); otherwise the value is
implementation defined."
[Unfortunately there is no definition given of "congruent". It is likely
intended as a modular arithmetic congruence relation: "a congruent_to b (mode
n)" meaning (a-b) is an integral multiple of n. So: least non-negative m such
that (source_integer - m) is a integral multiple of (2**precision). I do not
expect that this would contradict the above C11/C99 material for the 3 value
representations that C11/C99 allow.]
===
Mark Millard
markmi at dsl-only.net
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "[email protected]"
