> On 04/08/2023 4:09 PM EDT Sampo Syreeni <[email protected]> wrote: > > > On 2023-03-26, robert bristow-johnson wrote: > > > Title says it all. > > I don't really know. However, even in IEEE 754-1985, the double > precision is defined as a 64-bit format, and the handling of denormals > is the same as everywhere. So, if a processor claims compliance with > said standard, it would be expected that denormals would be handled as > usual. > > If not, make a media havoc of it. > > > If there are processors with FPUs that don't deal with denorms and > > cause an exception, I would be interested in knowing who the black > > sheep and the white sheep are. > > Again, don't know. As I (vaguely) remember it, the standard actually > allows throwing an exception here. That's because of the push towards > RISC at the time. Since denormals are a bit diffiult to handle in > hardware, it was thought putting in a dispensation for a slow path right > here would be warranted on average efficiency grounds.
So this is what I wonder about. The SHArC is still alive, but is about the only dedicated DSP that is. I know with your PC there is lotsa latency for a real-time process and with a Mac there is some latency but it's better controlled. At least that's my understanding. Now, suppose someone is either using a laptop or is making a product that uses an ARM or whatever. And not using any DSP coprocessor in the ARM. Like a DSP, they wanna get as much done with the CPU bandwidth as they can. All of their processes are designed for real-time application. They got the buffering down, figured out how to do the really sophisticated stuff (like something using an FFT or some other big transform) and parsing the work over multiple sample blocks. But they're pushing the computational load close to the bandwidth edge. Also, especially if it's a 64-bit processor, we should simply be able to do all of our DSP using doubles and never worry about quantization error until the *very* last step when a sample is getting outputted as an integer and either going to a DAC or getting written to a file using integer values (like mastering to a red-book CD). Of course, at that step, you should properly dither and noise shape. But quantization and overflow (saturation) should not be a concern in any other part of the process because you're doing it using 64-bit double. Now, we have known that if you're doing an IIR filter (or something else with recursion) that when the algorithm is excited with a non-zero signal and then after it, dead silence goes in, the output will decay exponentially and will eventually get into the realm of denormals. My question is, *when this happens*, will that newfangled 64-bit processor choke on it and throw an exception? Or even take more instruction clocks to deal with the denormal? It shouldn't. We should not now, with a modern 64-bit processor, have to give up on the blessings of denormal processing just because they didn't deal with it in the logic of the FPU. It's not that much more processing, when the FPU is presented with a denorm (which is an biased exponent of 0), it does not inject the "hidden 1 bit" and it uses the same exponent internally as if the biased exponent was 1. It's just a few gates, it shouldn't even take another clock. We've been talking about this for decades that, soon, DSP chips will become mostly obsolete because we'll just do it all with an standard CPU (seems like it's either Intel, AMD, or somebody's ARM). Even for a hardware product. Even for low power (there are some decently low-powered ARMs with an FPU). We need to make sure our DSP code will avoid division-by-zero and other mathematically prohibited operations (like sqrt of negatives in a real-valued expression). We can be careful and never get a NaN nor an Inf, that will cause the CPU to choke on an exception. But we should not have to worry about denorms and have to set the FTZ and DAZ bits to avoid denorm exceptions There should be no denorm exceptions anymore. Whether it's single or double precision. We're well into the 21st century. Denorms should be just another floating-point value. Anyway, that's my rant about it. -- r b-j . _ . _ . _ . _ [email protected] "Imagination is more important than knowledge." . . .
