1

X86 has two interesting flags that can be set in the dynamic floating-point environment which affect treatment of subnormals. FTZ (flush-to-zero) says that in any case when a subnormal result would be produced, 0 is produced instead. DAZ (denormals-are-zero) says that all subnormal operands are treated as though they were 0.

I think §8.2 of ieee 754 accounts for FTZ:

Associating a resuming alternate exception handling attribute with a block means: handling the implied exceptions according to the resuming attribute specified, and resuming execution of the associated block. Implementations should support these resuming attributes:

...

substitute(x)

Specifiable for any exception: replace the default result of such an exceptional operation with a variable or expression x. The timing and scope in which x is evaluated is language-defined.

...

abruptUnderflow

When underflow is signaled because a tiny non-zero result is detected, replace the default result with a zero of the same sign or a minimum normal rounded result of the same sign, raise the underflow flag, and signal the inexact exception.

(I don't remember the behaviour of FTZ in directed rounding modes, but one of the above should cover it.)

Is any allowance made for DAZ? I didn't see any.

phuclv
  • 37,963
  • 15
  • 156
  • 475
Moonchild
  • 483
  • 1
  • 4
  • 15
  • I don't think DAZ is IEEE-754 compliant. FWIW even FTZ is [not considered compliant by ARM](https://developer.arm.com/documentation/den0042/a/Floating-Point/Floating-point-basics-and-the-IEEE-754-standard): "For performance reasons, such denormal values are often ignored and are flushed to zero. This is strictly a violation of IEEE-754, but denormal values are used rarely enough in real programs that the performance benefit is worth more than correct handling of these extremely small numbers" – Margaret Bloom Mar 12 '23 at 14:28
  • This might be a clue: *Intel 64 and IA-32 Architecture Software Developer’s Manual*, December 2017, Volume 1, clause 10.2.3.3, says “… The flush-to-zero mode is not compatible with IEEE Standard 754…” However, that appears to be written in contemplation of the normal exception handling, not the alternate exception handling. – Eric Postpischil Mar 12 '23 at 21:29
  • It looks like, contrary to my post, FTZ is not compatible with any alternate exception handling mode. Since it always gives a zero, regardless of rounding mode (so abruptUnderflow doesn't cover it), but that zero has the correct sign (so substitute(±0) doesn't cover it). (substituteXor(0) looks likely, but apparently can only be used for multiplication and division, so it doesn't cover e.g. -0 + -0.) – Moonchild Mar 13 '23 at 05:19

0 Answers0