My system doesn’t seem to like it when I call NaN(2):

cpu%% cat tnan.c
#include
#include

void
main(int, char**)
{
double d = NaN();
print("d = %%f\n", d);

exits(0);
}
cpu%% 8c -FVw tnan.c
cpu%% 8l tnan.8
cpu%% 8.out
8.out 55798: suicide: sys: fp: invalid operation fppc=0x10a4 status=0x8081 pc=0x00001028
cpu%% acid 55798
/proc/55798/text:386 plan 9 executable

On 2/20/07, Joel Salomon gmail.com> wrote:

A simpler test case:

#include
#include

void
main(int, char**)
{
NaN(); // ☹

exits(0);
}

--Joel

Playing with acid a bit:

cpu%% cat tnan.c
#include
#include

void
main(int, char**)
{
NaN(); // ☹

exits(0);
}
cpu%% 8c -FTVw tnan.c
cpu%% 8l -o tnan tnan.8
cpu%% tnan
tnan 55986: suicide: sys: fp: invalid operation fppc=0x108d status=0x8081 pc=0x00001028
cpu%% acid -l acme 55986
/proc/55986/text:386 plan 9 executable

/sys/lib/acid/port
/sys/lib/acid/acme
/sys/lib/acid/386
acid: stk()
At pc:0x00001028:main+0x8 /usr/chesky/src/hak/lex/tnan.c:7
main()
called from _main+0x31 /sys/src/libc/386/main9.s:16
acid: regs()...

fwiw, i think the gas construction syntax is this:

dd 44 24 04 fldl 0x04(%%esp,1)

this might be an alignment problem. but that's a wild guess.
you could rewrite NaN in assembler and adjust the stack frame
by hand.

you need a processor manual.

- erik

I think not:
acid: SP
0x00000044

I could. It’s just hard to believe I’m the first to run across this
problem with NaN(2).

Have a few at home. Trouble is, I’m at school now.

FLD, got it. I’m trying to get acid to dump the hex bytes of the
FMOVD instruction so I can confirm that these are the same, but I’m not finding it in the manual.

--Joel

after a bit of actual thought, i think that NaN
is supposed to generate a note. if you do catch
the note, the program should work fine.

e.g.

#include
#include

void
note(void *, char *s)
{
if(strncmp(s, "sys: fp: ", 8) == 0)
noted(NCONT);
noted(NDFLT);
}

void
main(void)
{
double d;

On 2/20/07, erik quanstrom coraid.com> wrote:

This is distinct from sNaN/qNaN, right?

--Joel

On 2/20/07, erik quanstrom coraid.com> wrote:

That was it; thanks.

--Joel

On 2/20/07, Joel Salomon gmail.com> wrote:

That is the default behavior. See getfcr(2). In particular,
if you add

setfcr(getfcr()&~FPINVAL);

to your program then you can carry NaNs around willy-nilly
without causing exceptions.

On 2/20/07, Joel Salomon gmail.com> wrote:

This tells you that SP's "address" is 0x44. (The registers appear to
have memory addresses starting at 0 in acid.) If you want to find
out what SP is, you have to dereference it, as in *SP.