[L2Ork-dev] PD_BIGORSMALL

[Matt Barber]

I don't know how that actually works because for CPUs that don't support
denormal arithmetic or bash them to zero it can go to a software assist,
but I'm not sure where in the chain that happens. I don't think there's any
solid way to avoid doing a computation that results in a denormal or having
to zero one out once it's there. If I had to guess, I'd wager that the
assist doesn't kick in until you try to do something with one. If you want
something that will catch just denormals it's easy, but notice also that
PD_BIGORSMALL also tags infs and nans for free.


On Mon, May 21, 2018 at 2:05 PM, Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> >> 4. Just curious-- why the choice of 0x20000000 for the cutoff?
> >
> >
> > Because it's very fast and gets a reasonable range for high and low that
> are
> > roughly inverse magnitude.
>
> So technically, we have no macro to test for denormals. Instead, we have a
> check for numbers past a given conservative threshold, and that check can
> be
> used to keep most filters from ever arriving at denormal values. (Again,
> just
> trying to be as precise as possible.)
>
> Also, just for my own curiosity:
> Suppose math.h did indeed have a fast-tracked issubnormal function.
> Would that be sufficient to keep dsp algorithms from hitting a slow
> branch? Or does a computation that results in a denormal (or even zeroing
> out a
> denormal) cause a slow-path computation?
>
> -Jonathan
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20180521/fc8f3437/attachment.html>