From owner-svn-src-head@freebsd.org Thu Mar 3 11:22:47 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4922A93B6B for ; Thu, 3 Mar 2016 11:22:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-158.reflexion.net [208.70.211.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA53DB20 for ; Thu, 3 Mar 2016 11:22:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31459 invoked from network); 3 Mar 2016 11:23:03 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 3 Mar 2016 11:23:03 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Thu, 03 Mar 2016 06:22:49 -0500 (EST) Received: (qmail 15966 invoked from network); 3 Mar 2016 11:22:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 3 Mar 2016 11:22:49 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4DAB11C43D2; Thu, 3 Mar 2016 03:22:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: svn commit: r296336 - in head/sys: dev/bhnd dev/pccard dev/pci isa kern sys x86/xen From: Mark Millard In-Reply-To: <42B9FE2E-95D7-4292-9A27-7E4F24BCEDCD@dsl-only.net> Date: Thu, 3 Mar 2016 03:22:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <54D250A4-C855-4B37-8D3E-F4EFE975B7B2@dsl-only.net> References: <42B9FE2E-95D7-4292-9A27-7E4F24BCEDCD@dsl-only.net> To: Justin Hibbits , svn-src-head@freebsd.org X-Mailer: Apple Mail (2.2104) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 11:22:48 -0000 [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