> 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=