social.noyu.me

@hikari I considered using a quiet NaN once for storing nulls for a database. I don't see much use for a signalling NaN. In that case, an actual error value seems preferable.

@hikari i'm not even sure which, if any, of the systems i've ever used/developed for actually support the signaling features.

@mcc @hikari At the HW level, x86 and Apple's more recent ARM cores do. Actual language/SW/tooling support is spottier.

@steve @mcc @hikari On x86, you can disable throwing actual exceptions on sNaNs. The MXCSR register has "sticky" bits that you can clear before a sequence, then check afterwards. If there were any sNaNs read or produced during the sequence, the "Invalid Operation" sticky bit will be set. I believe qNaNs do not set the sticky bits.

This is rather klunky to use, and relies on the language/library having support for reading/setting the MXCSR, but it can be done.

@TomF @mcc @hikari That's the default behavior; you have to _enable_ trapping on sNaN.

qNaN does not set sticky bits except for operations that have no other means to preserve the NaN: comparisons and conversions to integer.

(MXCSR defaults to 0000_1F80h, i.e. all exceptions masked)

@steve @mcc @hikari Is the question, "does anyone use snans directly" or does using the fp control registers to make all nans signal count. because we do the latter (and I believe it's reasonably common). (granted, we then combine this with fast-math so it's all kinds of nightmare, but anyway)

@dotstdy @mcc @hikari "We unmask invalid and run under fast-math" is some sort of shortest compiler-writer horror story entry.

@dotstdy @mcc @hikari Yes, I would like several hundred ud2 instructions sprinkled randomly throughout my program. I will definitely not regret this.

@steve @mcc @hikari my favorite part is when people work hard to write explicit nan checks and handling, which then immediately get thrown away by the compiler. (which leads to a fun escalating war of detecting nan in obtuse ways, I'm sure some smartass in compiler land is going to get clever with bit patterns one day and break all the explicit via-integer checks too, this is all only in internal builds, at least, but it's a bit funny)

@dotstdy @mcc @hikari we went to some length to avoid this in Apple's math.h, so you get a fast inline test when __FINITE_MATH_ONLY__ == 0 and a mandatory function call if you turn on fast-math. This still can't catch everything.

@steve @mcc @hikari Another fun case is when you generate nans with fast math, but don't without. Feels very Congrats, You Played Yourself.

@steve @hikari Does the specific phrasing "Apple's more recent ARM cores" suggest that other ARM cores do not

@mcc @steve @hikari I think this is a reference to the early iPhone cores. AFAIK all the m series chips deal with sNaNs properly

@mcc @hikari Support for trapping on sNaN is optional, and many implementations do not do it, yes. They will get the right result, but you can't stop the world on an invalid operation.

@hikari Some Common Lisp implementations do, and convert the HW exception to regular conditions.