Subject: Re: [linux-audio-dev] Denormalisation considered harmful?
From: eli+@gs211.sp.cs.cmu.edu
Date: Tue Dec 12 2000 - 04:58:23 EET
Paul Barton-Davis wrote:
> I have an even better way that involves basically no CPU cycles. This
> is from snd:
[...]
> int __fpu_ieee = _FPU_IEEE;
> _FPU_SETCW(__fpu_ieee);
[...]
> this turns off the interrupt for denormals.
Try it -- what I see is that a multiply involving a denormal continues
to take 250+ cycles.
Denormals aren't slow because of an IEEE floating-point exception.
It may be that the hardware, not handling denormals directly, throws
an interrupt to some piece of code that performs the calculation --
I don't know. But whatever goes on is under the hood, and essential
to computing denormals in accord with the IEEE spec. You can't turn
it off, not on Intel hardware.
Within the IEEE spec[*] you can, if you like, turn _on_ the denormal
exception; it's masked by default. You'll know if it's unmasked,
because it will dump your core unless you explicitly handle it.
[*] actually the denormal exception is Intel's addition, but it's
in keeping with the five IEEE-mandated exceptions.
As far as I know, there is no way to make denormals not be slow on
Intel. People try various IEEE control tricks with exception masks
and precision control, but IEEE won't let you flush denormals to zero.
And Intel does not deviate on this. Please correct me on this -- I'd
love to hear it.
So you do tricks like adding DC offset or zeroing small numbers, as
Steve Harris discussed. The first seems like it ought to be faster --
no branch, and no moving between the FPU and ALU register files -- but
I don't measure a difference, and the second is less nasty IMO.
Terminological quibble -- the macro Steve posted was named DENORMALISE(),
which sounds to me like it's taking a normalized value and making it
denormal. What it actually does is take a denormal and make it zero.
I'd like to call it FLUSH_TO_ZERO().
I'm curious how operations on denormals are computed, whether by a
handler is in the kernel, in which case the kernel could be modified,
or in some firmware, or what. I fail to find any such handler
in the Linux kernel. Intel has some discussion up about IA-64:
http://developer.intel.com/technology/itj/q41999/articles/art_6i.htm
http://developer.intel.com/technology/itj/q41999/articles/art_6j.htm
> For example, on Itanium[tm], denormal faults are signaled by software
> (the IA-64 Floating-Point Emulation Library) after they are reported
> initially by the hardware as Itanium-specific SWA faults. SWA faults
> that are not converted to denormal faults (because denormal faults are
> masked) cause the result to be calculated by software. Whether the
> result of a floating-point instruction is calculated in hardware or in
> software, it can further signal other floating-point exceptions (traps).
> SWA requests are treated like regular floating-point exceptions, but
> they are always 'unmasked' and handled by an SWA handler represented
> by the IA-64 Floating-Point Emulation Library. The library is able to
> calculate the result for any IA-64 arithmetic floating-point
> instruction. When an SWA fault or trap occurs, it is processed and the
> result is provided to the operating system kernel.
So where does this Emulation Library live?
--
Eli Brandt | eli+@cs.cmu.edu | http://www.cs.cmu.edu/~eli/
This archive was generated by hypermail 2b28 : Tue Dec 12 2000 - 05:54:54 EET