0

The IEEE floating point standard defines several exceptions that occur when the result of a floating point operation is unclear or undesirable: underflow, overflow, inexact, invalid, and divide-by-zero.

As you can see, such exceptions could occur quite frequently: even 0.2+0.1 should trigger the inexact exception. For a piece of numerical code involving N floating-point instructions, N/2 or more might trigger at least one of these exceptions. So I wonder how the OS works to avoid the performance overhead of constantly triggering these exceptions?

zell
  • 9,830
  • 10
  • 62
  • 115
  • [ARM says](https://developer.arm.com/documentation/ddi0274/h/exception-handling/inexact-exception) *The VFP11 coprocessor handles the Inexact exception differently from the other floating-point exceptions. It has no mechanism for reporting inexact results to the software, but can handle the exception without software intervention as long as the IXE bit, FPSCR[12], is cleared to 0, disabling Inexact exceptions.* – Weather Vane Sep 24 '22 at 08:31
  • Related: [Visual Studio always breaking on "Floating-point inexact result"](https://stackoverflow.com/questions/49101353/visual-studio-always-breaking-on-floating-point-inexact-result) – Weather Vane Sep 24 '22 at 08:35
  • @WeatherVane How is that related? – zell Sep 24 '22 at 09:00
  • What has the question to do with C? – Weather Vane Sep 24 '22 at 09:07
  • The 0.2 and 0.1 don't exist after compilation. The code only contains nearest float values. – stark Sep 24 '22 at 11:24

1 Answers1

1

Floating-point exceptions are not operating-system or process exceptions. The common default mode is that floating-point exceptions raise a flag in the floating-point status register and deliver a default result for the operation but do not trigger a change of program control. No trap routine is called. The operating system is not informed and does not notice. The floating-point instruction performs much like an integer arithmetic instruction. (However, the need to update a global status register can cause serialization in some processor architectures. Some architectures are designed to avoid this unless the register is read.)

If a process does change the mode so that floating-point exceptions do cause traps, then performance may be affected, especially with the inexact exception.

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312
  • Thanks. I understand what you said "If a process does change the mode so that floating-point exceptions do cause traps, then performance may be affected". The question is, since inexact floating-point computations, which is everywhere, trigger the exception, why is that not causing performance overhead? I assume some computation is needed to determine whether a computation is indeed exact. In other words, deciding whether a fp exception should be triggered, and actually setting the exception flag in the register as you said, should need some CPU cycles and not be 100% free ? – zell Sep 24 '22 at 09:21
  • @zell: Determining whether the result is inexact is part of the ordinary calculations of the result. The exact method depends on the operation being performed, but it is largely a matter of whether or not there are non-zero digits not being included in the significand of the delivered results. – Eric Postpischil Sep 24 '22 at 10:32
  • https://en.cppreference.com/w/c/numeric/fenv might be a useful reference. `fetestexcept` is used to check whether an FP exception has occurred and how these are separate from other exceptions – Sam Mason Sep 27 '22 at 14:13