Date: Thu, 3 Mar 2016 10:54:06 -0800 From: Mark Millard <markmi@dsl-only.net> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, Justin Hibbits <chmeeedalf@gmail.com> Subject: Re: svn commit: r296336 - in head/sys: dev/bhnd dev/pccard dev/pci isa kern sys x86/xen Message-ID: <3B2E571A-C682-4BAD-8DEE-12DE29AAD33C@dsl-only.net> In-Reply-To: <54D250A4-C855-4B37-8D3E-F4EFE975B7B2@dsl-only.net> References: <42B9FE2E-95D7-4292-9A27-7E4F24BCEDCD@dsl-only.net> <54D250A4-C855-4B37-8D3E-F4EFE975B7B2@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu Mar 3 06:18:48 UTC 2016 Bruce Evans wrote:
> On Thu, 3 Mar 2016, Justin Hibbits wrote:
>=20
> > Log:
> > Replace all resource occurrences of '0UL/~0UL' with '0/~0'.
> >
> > Summary:
> > The idea behind this is '~0ul' is well-defined, and casting to =
uintmax_t, on a
> > 32-bit platform, will leave the upper 32 bits as 0. The maximum =
range of a
> > resource is 0xFFF.... (all bits of the full type set). By dropping =
the 'ul'
> > suffix, C type promotion rules apply, and the sign extension of ~0 =
on 32 bit
> > platforms gets it to a type-independent 'unsigned max'.
>=20
>=20
> Why not use the correct signed value? This value is -1, not the =
value, if
> any, with all bits 1. All bits 1 might be a trap representation, but =
it
> is unclear if ~0 can give a trap representation or a trap since it is
> unclear if the '~' operation acts on padding bits. It is clear that =
all
> bits 1 gives has value -0 in 1's complement if there are no no padding
> bits. But -0 has the same value as +0. When converted to an unsigned
> type, it loses all traces of its sign, and becomes plain (ufoo_t)0.
>=20
> I don't like the plan to change the resource range type to uintmax_t.
> 64 bits is just bloat for most 32-bit systems. After fixing all the
> hard-coded u_longs, you can just use a typdefed type which should be
> uint32_t if possible.
>=20
> Bruce
My original attempt to send svn-src-head a note on this did not seem to =
go through.
I tried to interpret C11, C99, and part of C++11 on the point for =
C11/C99's allowed value representations, other than the familiar/common =
2's complement. As usual for me this is based on just the language =
standards. Other standards may have other rules.
I'm including it below. May be it will make it though this time?
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On 2016-Mar-3, at 3:22 AM, Mark Millard <markmi at dsl-only.net> wrote:
[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?3B2E571A-C682-4BAD-8DEE-12DE29AAD33C>