[9fans] Floating point and dividing by 0

[9fans] Floating point and dividing by 0

[Riddler]

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

Hello again,

Continuing on with my floating point adventures, I have a question that I
hope someone can provide some input on.

I'm general idea of what I'm doing the following:
    double zero = 0.0;
    notify(fpnotecatch); //Ignore divide by zero note for a moment
    double pInf = 1.0/zero;
    notify(0); //Back to default note handler

    if(isInf(pInf, 1) <= 0 && isInf(pInf, 0) <= 0) exits("Divide by zero
did not result in infinity");

The error "did not result in infinity" is always tripped. My understanding
is that according to the spec it should have resulted in either + or -
infinity.

I suspect it's not required as there was a note thrown instead, and I can't
think of any reason why you would deliberately ignore the note like I do of
the top of my head. Thought I would mention it anyway see what input you
guys had.

Regards,
Rid.

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

Re: [9fans] Floating point and dividing by 0

[erik quanstrom]

On Fri Apr 18 15:54:00 EDT 2014, riddler876@gmail.com wrote:

> Hello again,
>
> Continuing on with my floating point adventures, I have a question that I
> hope someone can provide some input on.
>
> I'm general idea of what I'm doing the following:
>     double zero = 0.0;
>     notify(fpnotecatch); //Ignore divide by zero note for a moment
>     double pInf = 1.0/zero;
>     notify(0); //Back to default note handler
>
>     if(isInf(pInf, 1) <= 0 && isInf(pInf, 0) <= 0) exits("Divide by zero
> did not result in infinity");
>
> The error "did not result in infinity" is always tripped. My understanding
> is that according to the spec it should have resulted in either + or -
> infinity.
>
> I suspect it's not required as there was a note thrown instead, and I can't
> think of any reason why you would deliberately ignore the note like I do of
> the top of my head. Thought I would mention it anyway see what input you
> guys had.

which kernel is this with?  also, be sure to note the fcr (see getfcr(2)).


- erik

Re: [9fans] Floating point and dividing by 0

[erik quanstrom]

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 <u.h>
#include <libc.h>

void
main(void)
{
	double zero, r;

	setfcr(getfcr() & ~FPZDIV);

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

Re: [9fans] Floating point and dividing by 0

[Riddler]

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

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 <quanstro@quanstro.net>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 <u.h>
> #include <libc.h>
>
> void
> main(void)
> {
>         double zero, r;
>
>         setfcr(getfcr() & ~FPZDIV);
>
>         zero = 0.;
>         r = 1.;
>         r = r/zero;
>         print("%g\n", r);
>         exits("");
> }
>
>

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

Re: [9fans] Floating point and dividing by 0

[erik quanstrom]

> 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?

i think charles might give a better answer.

but i think i overstated the "exactly where it left off" bit.  some hardware
may make edge cases really hard.  and i haven't looked up the details of
the 8087, and there is the possibility that your VM isn't exactly right.

- erik

Re: [9fans] Floating point and dividing by 0

[Riddler]

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

I imagine I was expecting a bit much. I was expecting that it would execute
the instruction, thus putting infinity in the variable, then trigger a
"divide by 0" note. Meaning if I continued infinity would be there.

Thinking about it in hindsight, I could see the CPU/FPU/X doing "get
instruction -> check divisor -> trigger interrupt". With fcr deciding if
the last step is "trigger interrupt" (assuming interrupts are triggering
the note) or "return infinity".
​
I can certainly see potential for lots of hardware edge cases, and why
doing this the way I am probably isn't a safe.

Thinking about the 'skipping an instruction' thing. I imagine you have to
or you would never be able to continue from any note that was triggered due
to an instruction in the program. At least not without some logic in the
note system to check what triggered it, where and ignore it if needed.
Wouldn't be so keen on it if the note was triggered by another program or
something though.
Might go look at the note system, I'm curious how these situations are
handled now.

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

Re: [9fans] Floating point and dividing by 0

[erik quanstrom]

> Thinking about the 'skipping an instruction' thing. I imagine you have to
> or you would never be able to continue from any note that was triggered due
> to an instruction in the program. At least not without some logic in the
> note system to check what triggered it, where and ignore it if needed.

certainly if you have an illegal instruction you may need to look at notejmp
(see setjmp(2)).

but more practically...

you can catch notes triggered by syscalls, and of course, the ancient bourne
shell trick of using a page fault note (er, well really signal, since the bourne
shell is a unix program) to ask for more memory will allow for the restarting
of the faulting instruction.  and it better not be skipped!

- erik