[Cfp-interest 2049] Re: Subnormals

[Jim Thomas]

> On Jun 28, 2021, at 11:58 AM, Fred J. Tydeman <tydeman at tybor.com> wrote:
> 
> On Sun, 27 Jun 2021 16:15:29 -0700 Jim Thomas wrote:
>> 
>> Some general comments 
>> 
>> It's common for CPUs to have behavior-changing controls that can be changed at execution time. Implementations
>> should generally be able to define characteristics of their floating-point arithmetic based on a default configuration of such
>> controls. For example, an implementation on a 754 CPU with trap enablement modes should be able to conform to Annex
>> F, even though a user might enable traps thereby causing non-conforming behavior. Also, C doesn't provide a way for a
>> user to change the behaviors related to subnormals and underflow. A program that does so is going outside the C
>> standard. I think we should avoid "changeable at runtime".
> 
> I removed that from the proposal.
> 
>> IEC 60559 is a well-defined floating-point standard. We don't have a viable more general standard (LIA?) that covers
>> arithmetics that don't conform to IEC 60559. There are limitless possibilities. I don't think C should try to characterize
>> non-standard behaviors just because they appear in an implementation. It might be different if a behavior is widely
>> adopted in a uniform way. Are we trying codify some such existing practice?
> 
> ARM chips, as far as I know, are in most cell phones.  So, they are widely adopted.

Maybe someone from ARM should propose C extensions that are suitable for their architecture. Non-IECC 60559 features seem out of scope for CFP.

> But, I do not know what state the FPU control bits are in.  I have made that part optional.
> 
>> What is the purpose of the macro? Presumably, it is intended to tell a program something useful about the arithmetic.
>> Considering the scope of possibilities for how subnormals might be treated, how can this macro provide information that
>> code might be based on? Are there examples of real code that uses it? If so, how do they use it?
> 
> Again, I made the other *_HAS_SUBNORM values be optional.
> While the user is only asking about *_HAS_SUBNORM == 0,
> I have looked at the more general case that I have encountered in my FPU testing.

I don’t understand how this answers the questions. Is testing the only use of the macro?
> 
>> "Flush to zero" is not defined and is used only once in C, in a footnote. A related problem is that the operations that flush
>> results to zero would need to be identified (or characterized). For example, would negate (-), fabs, and copysign be
>> expected to flush to zero? How about conversion to same or wider format?
> 
> I would expect all FP operations to be consistent on flushing; either all or none.

The ARM documentation says VABS and VNEG signal no exceptions. This suggests that they might not handle subnormals like other floating-point instructions.

> I believe that adding flushed subnormals shall be treated as zeros defines
> their behaviour.

I believe ARM FTZ mode causes subnormal results to be set to zero. Saying it treats them as zero suggests that they are still subnormal (in some sense).

> 
>> Some specific comments (in brackets) 
>> 
>> So, if subnormal operands are treated as zero, then subnormal numbers could be considered as non-canonical
>> encodings of zero.
>> 
>> [Comment: The words here confuse the distinction between the representation and the value. Consider changing the
>> sentence above to:  if subnormal representations are treated as zero values, then they can be regarded as
>> non-canonical zero representations.]
> 
> Changed.
> 
>> That would mean (independent of flushing subnormal results):
>> 
>> ...
>> 
>>        nextdown(minimum normal) is true zero. [Comment: Why "true" zero? Does true zero mean canonical zero?
>> Functions for such implementations are not required to produce canonical results.]
> 
> Yes, changed. 5.2.4.2.2#6 has:
> 
>  Typically, floating-point operations deliver results with canonical representations.

Not a requirement. 

>  IEC 60559 operations deliver results with canonical representations, unless specified otherwise.
> 
>>       signbit(-subnormal) is same as signbit(1.e0 * -subnormal); [Comment: Why?] which could be positive (zero).
>> [Comment: I don't think we've said anything about how implementations that treat subnormal representations as zero
>> values must treat the sign bit of such representations.]
> 
> I expect a bare operand and an operand in an expression to be treated the same.

In the absence of a requirement, I wouldn’t expect library functions to be consistent (with the HW or the compiler or each other).

> I added some washy words about the sign.
> 
>> However, if subnormal operands are NOT treated as zero, that would mean (independent of flushing subnormal results):
>> 
>> ...
>>       iscanonical(subnormal) is true (non-zero). [Comment: Depends on whether the representation of the subnormal
>> is canonical.]
> 
> Agreed.  But since subnormals have the minimum exponent, can one value
> have more than one representation?

Yes. For example, for IEC 60559 decimal formats, decimal encodings have non-canonical declets.

> Attached is an updated version.

I’m afraid we’re trying to specify something we don’t have the time or representation to do properly, and that is outside our scope. Given that the current specification of the type_HAS_SUBNORMAL macro is flawed and doesn’t seem to be useful as is, should we propose removing it?

- Jim Thomas



> 
> 
> ---
> Fred J. Tydeman        Tydeman Consulting
> tydeman at tybor.com      Testing, numerics, programming
> +1 (702) 608-6093      Vice-chair of PL22.11 (ANSI "C")
> Sample C99+FPCE tests: http://www.tybor.com
> Savers sleep well, investors eat well, spenders work forever.
> 
> <SUBNORM.ZIP>