Date: Thu, 3 Mar 2016 03:22:44 -0800 From: Mark Millard <markmi@dsl-only.net> To: Justin Hibbits <chmeeedalf@gmail.com>, svn-src-head@freebsd.org Subject: Re: svn commit: r296336 - in head/sys: dev/bhnd dev/pccard dev/pci isa kern sys x86/xen Message-ID: <54D250A4-C855-4B37-8D3E-F4EFE975B7B2@dsl-only.net> In-Reply-To: <42B9FE2E-95D7-4292-9A27-7E4F24BCEDCD@dsl-only.net> References: <42B9FE2E-95D7-4292-9A27-7E4F24BCEDCD@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[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 =3D=3D 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:=20
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) =3D 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.]
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54D250A4-C855-4B37-8D3E-F4EFE975B7B2>