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

> 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

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

On Mon May 2 12:30:03 PDT 2016, rym...@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

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

>> cpu% seq nan >> seq 11791387: suicide: sys: fp: invalid operation fppc=0x2635 status=0x8081 >> pc=0x122 > 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

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

Not crash into a flaming ball of (very vague) fire? On Mon, May 2, 2016 at 2:17 PM, erik quanstrom wrote: > On Mon May 2 12:07:58 PDT 2016, cinap_len...@felloff.net wrote: > > > > > file under: awk was really designed for pre-posix unix. :-) > > > > its not just about

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

On Mon May 2 12:07:58 PDT 2016, cinap_len...@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

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

> 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

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

> 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

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

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

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

On Sat Apr 30 05:53:04 PDT 2016, cinap_len...@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

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

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

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

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