> 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 neede
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 ->
> 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
I'm using the standard plan9 kernel running in a 32bit i386 VirtualBox VM.
The fcr (printed with %ulb) was 100100 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 wo
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
On Fri Apr 18 15:54:00 EDT 2014, riddler...@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(fpnoteca
