UnmaskedUnderflow (nope.delete@this.nope.org) on April 4, 2014 7:16 am wrote:
>
> Software types, pls stop writing denormal code. For posterity. :)

No, hardware types, stop sucking at denormals.

Here's why:

- some code actually does want denormals. It's rare, but it happens. I agree that those rare applications should have to work at it (clear the "flush-to-zero" bit or whatever), but since hardware designers made the default be "do denormals", hw people only have themselves to blame.

- but more importantly: it happens much more often by mistake, and if your hardware sucks at it, then your hardware sucks. It's that simple.

The "happens by mistake" is because it's really easy to overlook, and things still work. If your hardware model is "it will work, but it is slow", that "it will work" part translates directly to "nobody will notice that we're doing it".

So put the blame where it belongs: on hardware that silently does bad things. Don't blame software for not noticing those bad things when the hardware designers worked so hard at making the issue hard to notice!

So the fix is simple: don't suck at denormals, and don't blame the wrong party (sw).

This is not horribly unlike the unaligned scenario. Yes, unaligned accesses are harder for hardware. And yes, hardware that doesn't do them well is crap.

It really is that simple. If you have a fragile path, your hardware is bad and you should feel bad. As with unaligned accesses, being a few cycles slower is fine, because it is a more complicated path. But if it's more than a couple of cycles (say, an internal microfault to microcode), you damn well shouldn't blame software, you should look in the mirror and tell yourself "I'm a bad person".

Linus