From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <72d84d382ece571ee9be74a694b20d7d@ladd.quanstro.net> References: <72d84d382ece571ee9be74a694b20d7d@ladd.quanstro.net> Date: Fri, 18 Apr 2014 21:44:06 +0100 Message-ID: From: Riddler To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11361942f554c904f757356c Subject: Re: [9fans] Floating point and dividing by 0 Topicbox-Message-UUID: d9cc4c22-ead8-11e9-9d60-3106f5b1d025 --001a11361942f554c904f757356c Content-Type: text/plain; charset=UTF-8 I'm using the standard plan9 kernel running in a 32bit i386 VirtualBox VM. The fcr (printed with %ulb) was 1001000000 which seems to be FPPEXP and FPP DBL. Your code does indeed produce the expected output on my VM. So if my kernel isn't really doing the right thin; and the 'expected' behavior would be for my program to enter an infinite loop. Considering that's not happening (and assuming I understand correctly), perhaps something in notes/noted() needs looked at? On Fri, Apr 18, 2014 at 9:10 PM, erik quanstrom wrote: > i imagine what happened is your kernel doesn't really do the right thing > on catching the exception. i think the caught exception should restart > the program *exactly* where it left off, dividing by zero, which will lead > to an infinite loop. if your kernel skipped the instruction, then the > value > of (in my case r) would be whatever the previous value was. if this is the > statement that initializes r, this could be random trash on the stack. > which > would lead to a mystery exception later on for some value of trash on > stack. > > - erik > ---- > > this provides the correct result. > > #include > #include > > void > main(void) > { > double zero, r; > > setfcr(getfcr() & ~FPZDIV); > > zero = 0.; > r = 1.; > r = r/zero; > print("%g\n", r); > exits(""); > } > > --001a11361942f554c904f757356c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm using the standard plan9 kernel run= ning in a 32bit i386 VirtualBox VM.
The fcr (printed wit= h %ulb) was 1001000000 which seems to be FPPEXP and FPPDBL.<= br>
Your code does indeed produce the expected output on my VM.

So if my kernel isn't really doi= ng the right thin; and the 'expected' behavior would be for my prog= ram to enter an infinite loop. Considering that's not happening (and as= suming I understand correctly), perhaps something in notes/noted() needs lo= oked at?


O= n Fri, Apr 18, 2014 at 9:10 PM, erik quanstrom <quanstro@quanstro.net<= /a>> wrote:
i imagine what happened is your kernel doesn= 't really do the right thing
on catching the exception. =C2=A0i think the caught exception should restar= t
the program *exactly* where it left off, dividing by zero, which will lead<= br> to an infinite loop. =C2=A0if your kernel skipped the instruction, then the= value
of (in my case r) would be whatever the previous value was. =C2=A0if this i= s the
statement that initializes r, this could be random trash on the stack. =C2= =A0which
would lead to a mystery exception later on for some value of trash on stack= .

- erik
----

this provides the correct result.

#include <u.h>
#include <libc.h>

void
main(void)
{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 double zero, r;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 setfcr(getfcr() & ~FPZDIV);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 zero =3D 0.;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 r =3D 1.;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 r =3D r/zero;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 print("%g\n", r);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 exits("");
}


--001a11361942f554c904f757356c--