[Cfp-interest] Fwd: (SC22WG14.12723) Observations on N1631

[Jim Thomas]

Begin forwarded message:

> From: Jim Thomas <jaswthomas at sbcglobal.net>
> Subject: Re: (SC22WG14.12723) Observations on N1631
> Date: September 26, 2012 8:41:13 PM PDT
> To: "Joseph S. Myers" <jsm at polyomino.org.uk>
> Cc: SC22 WG14 <sc22wg14 at open-std.org>
> 
> Joseph,
> 
> Thank you for the detailed discussion. You've pointed out an area of the IEC 60559 binding to C that needs more consideration.
> 
> IEC 60559 refers (in increasing level of specificity) to:
> 
> data = floating-point numbers including +-0, +-infinity, NaN
> representations = (sign, exponent, significant) triples, +/-infinity, quiet NaN, signaling NaN
> encodings = bit strings for representations (not to be confused with the DPD an BID encoding schemes)
> 
> Some representations have non-canonical encodings as well as a canonical encoding. Encodings here might be thought of as bit strings for C value bits. Thus the C object representation is a still further level of specificity.
> 
> C refers to values and object representations. To fit the IEC 60559 abstractions to the C model, I think the IEC 60559 encodings do need to be regarded as C values (as you suggest). Another argument for this approach is that NaN payloads appear only at the encoding level.
> 
> The study group needs to go carefully throughout he C standard to see if this interpretation is, or can be made, consistent.
> 
> -Jim
> 
> On Sep 25, 2012, at 4:33 PM, Joseph S. Myers wrote:
> 
>> On Tue, 25 Sep 2012, Jim Thomas wrote:
>> 
>>>> Page 4: regarding canonical encodings, is the property of being canonical 
>>>> considered to be one of the full sizeof (floating-type) bytes of the 
>>>> object, or one excluding padding bits?  For example, if long double is x86 
>>>> extended, with 10 significant bytes, but sizeof (long double) is 12 or 16, 
>>>> including some tail padding, must canonical values be defined for the 
>>>> padding?  (I don't think doing so really makes sense - there is no 
>>>> requirement for implementations to preserve padding bits, or copy them 
>>>> when copying a value, and a value stored in registers may not have them, 
>>>> so it's hardly meaningful to say they take on particular values for a call 
>>>> to iscanonical.  But I'm not sure how you define, in a generic way, what 
>>>> noncanonical aspects of the encoding must be preserved, which would seem 
>>>> necessary for iscanonical on a value to make sense.)
>>> 
>>> Canonical is intended to be a property of the value bits, not any 
>>> padding bits. I don't understand your last point.
>> 
>> C11 6.2.6.1 paragraph 8 describes the existing rules for values with 
>> multiple representations:
>> 
>> Where an operator is applied to a value that has more than one object 
>> representation, which object representation is used shall not affect the 
>> value of the result.52) Where a value is stored in an object using a type 
>> that has more than one object representation for that value, it is 
>> unspecified which representation is used, but a trap representation shall
>> not be generated.
>> 
>> So, it's not meaningful to say that x+y has a particular representation 
>> (canonical or noncanonical) from among those for a value; it has a value, 
>> not a representation.  Only if stored in an object does it get a 
>> representation.  If passed to a function, the value then gets stored in a 
>> new object (the parameter to that function being an object inside that 
>> function), possibly with a new representation.  All this applies as much 
>> to different representations using value bits, as to bits that are purely 
>> padding bits.
>> 
>> But the iscanonical macro is defined (page 31) to act on a value, as if 
>> values rather than representations are canonical.
>> 
>> The canonicalize functions are defined to work on representations, which 
>> seems meaningful.  The problem is if you define "canonical" to relate to 
>> representations rather than values, but then expect to be able to query it 
>> for a value rather than a representation with iscanonical.  If you want 
>> iscanonical as defined to work, I think the noncanonical forms need to be 
>> defined somehow as different *values* in C terms, not just different 
>> *representations*.  Or define it to take a pointer so it can work on 
>> representations - then you need to state explicitly the intent as regards 
>> considering value bits but not padding bits.
>> 
>> (There may also be trap representations in a floating-point type - 
>> representations not corresponding to any value of that type.  With 
>> iscanonical taking a value, attempting to pass the value of an object with 
>> such a representation to iscanonical would result in undefined behavior.  
>> With it taking a pointer, I suppose you could define iscanonical to return 
>> 0 when passed a pointer to a trap representation, and the canonicalize 
>> functions to return a nonzero value because there is no corresponding 
>> canonical representation.)
>> 
>> -- 
>> Joseph S. Myers
>> joseph at codesourcery.com
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20120926/0ff17c42/attachment.html