[9fans] store NaN() to memory traps on 386 (387)

[9fans] store NaN() to memory traps on 386 (387)

[cinap_lenrek]

with spews recent native awk port, we'v discovered an issue
with strtod() that with the default FCR; which has FPINVALs
traps enabled; the FMOVDP instruction that stores a NaN to memory
traps. so it is not really possible to check for NaN result of
strtod() unless you mask the traps.

The APE port of awk got away with strtod() not recognizing
"nan" at all, while the native plan9 libc version does.

so the problem is that NaN() appears to be unusable with the
default FCR on 387, and we'd like to have consistent behaviour
under all archs when possible.

right now, the 387 seems to be the single oddball, so one idea
was to have NaN() return a quiet NaN for 387 only instead of a
signaling one.

On the other hand, one could argue that programs relying on
NaN's have to explicitely disable FPINVAL traps on all archs.

Any suggestions on how to resolve this?

--
cinap

Re: [9fans] store NaN() to memory traps on 386 (387)

[cinap_lenrek]

following up, theres another idea:

given that what we want is fp-arithmetic on NaN's to trap when FPINVAL
is set in the fcr, but not when doing simple assignments, what if we just
deal with it in the kernels exception handler for 387?

so when the store traps, and source operand is a SNaN, we just
emulate the instruction and carry on without delivering the note.

--
cinap

Re: [9fans] store NaN() to memory traps on 386 (387)

[erik quanstrom]

On Sat Apr 30 05:53:04 PDT 2016, cinap_lenrek@felloff.net wrote:
> with spews recent native awk port, we'v discovered an issue
> with strtod() that with the default FCR; which has FPINVALs
> traps enabled; the FMOVDP instruction that stores a NaN to memory
> traps. so it is not really possible to check for NaN result of
> strtod() unless you mask the traps.
>
> The APE port of awk got away with strtod() not recognizing
> "nan" at all, while the native plan9 libc version does.
>
> so the problem is that NaN() appears to be unusable with the
> default FCR on 387, and we'd like to have consistent behaviour
> under all archs when possible.
>
> right now, the 387 seems to be the single oddball, so one idea
> was to have NaN() return a quiet NaN for 387 only instead of a
> signaling one.
>
> On the other hand, one could argue that programs relying on
> NaN's have to explicitely disable FPINVAL traps on all archs.
>
> Any suggestions on how to resolve this?

i'll assume the context here is on initial conversion from input to fields.
vaguely the rule is anything that's properly representable as a number, is a number,
and anything else is a string.  since awk is well older than ieee, nan, inf,
one could easily argue they should count as strings.

so in my mind, this isn't an issue.  my solution would be if the string is nan,
then don't bother calling strtod.

the gawk maintainers while complaining about posix 2004, evidently agree,
providing --posix to disable filtering out nan and other strings from being
passed to strtod.

- erik

Re: [9fans] store NaN() to memory traps on 386 (387)

[cinap_lenrek]

my initial analysis was wrong. i got fooled by the asynchronous nature
of the exception delivery. the trap already happend on the FLD instruction
when we try to load the SNaN from memory.

what sucks is that passing "nan" to strtod() will result in a program
crash with the default fcr instead of rejecting the string. so everyone
is forced to filter the inputs to strtod() to avoid the crash, or change
the fcr and then deal with the nan's and infs.

--
cinap

Re: [9fans] store NaN() to memory traps on 386 (387)

[erik quanstrom]

> what sucks is that passing "nan" to strtod() will result in a program
> crash with the default fcr instead of rejecting the string. so everyone
> is forced to filter the inputs to strtod() to avoid the crash, or change
> the fcr and then deal with the nan's and infs.

file under: awk was really designed for pre-posix unix.  :-)

- erik

Re: [9fans] store NaN() to memory traps on 386 (387)

[cinap_lenrek]

> file under: awk was really designed for pre-posix unix.  :-)

its not just about awk. whenever you want to convert a string to
a floating point number under plan9 you'll have to deal with this
problem:

cpu% seq nan
seq 11791387: suicide: sys: fp: invalid operation fppc=0x2635 status=0x8081 pc=0x0000122f

--
cinap

Re: [9fans] store NaN() to memory traps on 386 (387)

[erik quanstrom]

On Mon May  2 12:07:58 PDT 2016, cinap_lenrek@felloff.net wrote:
>
> > file under: awk was really designed for pre-posix unix.  :-)
>
> its not just about awk. whenever you want to convert a string to
> a floating point number under plan9 you'll have to deal with this
> problem:
>
> cpu% seq nan
> seq 11791387: suicide: sys: fp: invalid operation fppc=0x2635 status=0x8081 pc=0x0000122f

that seems reasonable to me.  what could seq possibly do with nan?

- erik

Re: [9fans] store NaN() to memory traps on 386 (387)

[Ryan Gonzalez]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

Not crash into a flaming ball of (very vague) fire?

On Mon, May 2, 2016 at 2:17 PM, erik quanstrom <quanstro@quanstro.net>
wrote:

> On Mon May  2 12:07:58 PDT 2016, cinap_lenrek@felloff.net wrote:
> >
> > > file under: awk was really designed for pre-posix unix.  :-)
> >
> > its not just about awk. whenever you want to convert a string to
> > a floating point number under plan9 you'll have to deal with this
> > problem:
> >
> > cpu% seq nan
> > seq 11791387: suicide: sys: fp: invalid operation fppc=0x2635
> status=0x8081 pc=0x0000122f
>
> that seems reasonable to me.  what could seq possibly do with nan?
>
> - erik
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/

[-- Attachment #2: Type: text/html, Size: 1612 bytes --]

Re: [9fans] store NaN() to memory traps on 386 (387)

[erik quanstrom]

On Mon May  2 12:30:03 PDT 2016, rymg19@gmail.com wrote:

> Not crash into a flaming ball of (very vague) fire?

the obvious loop with nan

	for(i in `{seq nan >[2=]}){echo $i}

prints nothing, as the body is never executed.

what would you have it do?

to cinap's point, either nan -> float doesn't trap, and there is no protection
against bad fp math, or it does trap, and one has protection against producing
inadvertant nans.

by the way, the same issue exists with sse.

- erik

Re: [9fans] store NaN() to memory traps on 386 (387)

[cinap_lenrek]

> to cinap's point, either nan -> float doesn't trap, and there is no protection
> against bad fp math, or it does trap, and one has protection against producing
> inadvertant nans.

> by the way, the same issue exists with sse.

with SSE, i can assign SNaN's to variables and test for them with isNaN(). and only
have the cpu trap when doing arithmetic on them, which i think is reasonable.

but on 387, loading/storing the SNaN causes touble before i can even test for it.

if NaN() produces a QNaN instead of a SNaN, then arithmetic will silently produce
QNaN results, and we loose the protection for SSE. This is the behaviour when
one clears FPINVAL from the FCR.

for awk, i'm forced to one of these options with the current behaviour:
- test the string before calling strtol() to make sure its proper decimal real number
- clear FPINVAL in the FCR and loose the protection and test strtol() result with isNaN()

both suck. if i'm going to have to parse the real number string myself to make
sure its not nan, then what use is strtod()? and clearing FPINVAL just so i can
test for isNaN() makes no sense. the program wasnt prepared to handle nan in the
first place.

maybe strtod() should not even parse "nan" when the FPINVAL bits are clear in
the FCR an return 0.0 (similar to strtol) instead? So we interpret the FPINVAL
bits in the FCR as "we dont want NaN's" and hence never produce them ourselfs?

not sure whats worse...

--
cinap

Re: [9fans] store NaN() to memory traps on 386 (387)

[cinap_lenrek]

>> cpu% seq nan
>> seq 11791387: suicide: sys: fp: invalid operation fppc=0x2635 status=0x8081 pc=0x0000122

> that seems reasonable to me.  what could seq possibly do with nan?

thats the thing. its not expecting nan. and having the process trap
for this input seems rather drastic. imagine we'd make atoi() abort()
when the input isnt a valid integer and demand that every caller
of atoi() checks beforehand if the input string is a decimal number.
writing that check in case for real numbers is even more complicated
than writing a test for decimal integers.

--
cinap