svn commit: r296336 - in head/sys: dev/bhnd dev/pccard dev/pci isa kern sys x86/xen

[Mark Millard]

On Thu Mar 3 06:18:48 UTC 2016 Bruce Evans wrote:

> On Thu, 3 Mar 2016, Justin Hibbits wrote:
> 
> > 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'.
> 
> 
> 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.
> 
> 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.
> 
> 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?

===
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 == 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