> On Apr 13, 2023, at 11:11 AM, STEFFAN DIEDRICHSEN
> <0000009333a9e91c-dmarc-requ...@lists.columbia.edu> wrote:
>
> I constructed a digital vocoder out of a TMS320C30. In the documentation,
> denormals or FTZ isn’t even mentioned, it’s not IEEE conforming anyway. The
> only thing is “Underflows are handled, by settingthe result to zero and
> setting an underflow flag.” (SPRA397.pdf from ti.com)
Yeah - that’s FTZ (if the number is less than what is representable by a
normalized float [e.g. ±1 x 2^-max_exp], then the value is equivalent to zero,
and is represented as zero, rather than using the denormalized representation).
For single precision float that number is
±1 * 2^-126
anything closer to zero than than is represented as zero.
For double precision float that number is
±1 * 2^-1023
anything closer to zero than than is represented as zero.
so, for single precision, that means that signals with levels down to
-758.60 dBFS (relative to FS = 1)
and for double precision:
-6159.1 dBFS (relative to FS = 1)
So there is really nothing lost by FTZ for the sort of computations and signal
range values we use in audio signal processing.
The denorms are only an issue because exponential decay of state variables from
IIR structures will wander into the the denorm levels when fed with digital
black (all zeros). They won’t happen if, for example, the processor is fed with
the noise floor of an A/D stage.
The output of the filter will have become equivalent to 0 far earlier than the
state variable would have flushed to zero (generally about 566 dB earlier in
the decay, even if you assume 32-bit fixed values are representable in an
output signal).
Denorms are a problem only because the FPU (or worse, supporting system
software if the FPU doesn’t handle it in HW) has to do lots more work to
implement the denorm calculations, and they take 10x to 100x the number of
cycles to compute - for something that is not meaningful anyway.
Ideally all systems doing audio DSP just set the FPU to FTZ (or that is the
default mode - e.g. for NEON and most DSPs, and I think the SIMD extensions for
intel - although I am not 100% sure about that).
But sometimes the hosts don’t configure that and the performance hit is
substantial.
For audio DSP it doesn’t provide any real benefits, as any denorm value that is
added or subtracted to an audio-relevant value will be FTZ in the calc, and any
that is multiplied will be a denorm, and any that is divided will be an ∞. And
any denorm value that is converted to fixed point for D/A conversion will be 0
in fixed point.
So while zero cost support for denorms might be fine, there is no way to do it
at zero cost, and for audio not supporting denorms and just FTZ whenever they
are generated is actually the best thing to do.
> Back then it was an impressive workhorse with low power consumption, using a
> 40 bit floating point format, if needed.
Isn’t that the SHARC? The SHARC definitely had support for 40-bit float (which
was very cool - we used the heck out of it) but I though the TI floating point
DSPs only supported 32-bit/64-bit float but no 40-bit float.
> Daniel Weiss used it for his shiny EQ and compressor.
This 40 bit floating point still had the same denorm cutoff as 32-bit float. It
just had more precision in the mantissa up to the point of denormalization.
B.J. Buchalter
Metric Halo
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mhlabs.com&d=DwIFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=TRvFbpof3kTa2q5hdjI2hccynPix7hNL2n0I6DmlDy0&m=3aVhXL-pLIYaB_7flg7Th8WwAbRGLl1zXWGBBsQhPKYlzpl5WYcQ-IwO_wwekUfm&s=5mnFZRkAxlz9sej7v8LycGKEgDNTa_rXbJ95k5Gp_TM&e=
