UnmaskedUnderflow (whoawhoawhoa.delete@this.whoa.com) on April 4, 2014 11:45 am wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on April 4, 2014 8:54 am wrote:
> > 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
>
> Ha, fair enough, I'll own my little snark. Since it's you, I think I'll offer my penance in the
> form of a serious response. (I didn't think that this morning I'd be countering Linus...wow)
>
> I can't defend "denormals on by default". For legacy chips like x86/x87, that decision was made long ago
> and kept alive so 30-year old DOS/Fortran programs the govt owns will still work on upgrades with no recompile.
> Denormals in this case require a microtrap so they can 1.) respond to UNmasked specs via the 1985 IEEE-754
> requirement and 2.) to still send an FERR to the southbridge, as original FPs were not part of the main
> cpu. You'd think this and things like A20 bits would be gone by now, but they're not.
>
> FTZ/DAZ were added later. I wish they were on by default. I wish compilers forced them
> on by default. But such it is. Perhaps someone of your reputation could contact the
> ivory tower ISA greybeards and/or compilers to convince them so? I support that.
>
> For those who need denormals (HPC)...IBM makes several chips that support them in-line. The people who
> really need them (physicists, mathematicians, wave equations) know already and choose accordingly.
>
> For those who do them by mistake...it's a shame again the defaults are masked exceptions. If
> anything, the slower perf tells you there's a problem. Worse than the perf is that the math
> is wrong...it is by mere coincidence that a subset of integer math works when doing adds/subs
> in un-type-cast denormals. Anything non-trivial will be plain non-functional. For that, we cannot
> verify software's functionality. Sadly we don't help by not telling you by default.
>
> As for adding a few cycles? Yes, to calculate rounded denormals takes hardware and a few cycles more...if always
> masked. ARM chips are always masked, and their SIMDs automagically FTZ. Thus, when the software functionality
> is incorrect (let's say for a recent example, Geekbench 2 accessing uninitialized memory, as discussed on this
> very site) then a masked ARM chip will do it in a few cycles and an unmasked x86 will take a perf trap. Then
> the masses rejoice at the perf crown of ARM in a cross-compare that people said explicitly to avoid.
>
> For a small chip like that discussed here, denormal support is crippled on purpose. It,
> like any chip design, is a tradeoff. Small chips adding big hardware to denormal support
> is the wrong choice, now and always. Moore's Law -- fast denormals on phones?
>
> Hope that's a reasonable response. I'm a bad person. I'll get back to crippling denormals.
>
> Let me modify my snark. "Software types, pls take exceptions on denormals till hw un-stupids defaults"

The 32 bit ARM chips implement denormals properly in hardware for scalars but does FTZ for denormals in its SIMD. The low level x86 chips didn't even do it properly in hardware for scalars. Considering the crap they do implement I find that surprising.

The 64 bit ARM architecture implements denormals in its SIMD as well, and they also implement it properly in the later Mali GPU's as they see them being used for general compute tasks. You can ask for FTZ but that is for backwards compatibility rather than being a performance issue.

I think one can safely consider the ARM A53 core as being a small one.