Bug in FloatingPoint error handling ?

Hi

I think the following's a bug.  Try:

    [10.0 raisedTo: 2222] on: FloatingPointException do: [:err | ].
    10.0 raisedTo: 1000.

If I execute these lines separately, then the first evaluates to nil, and
the second throws an overflow exception.  I think that's as it should be.

If I execute the lines in one go, then no exception is thrown and the second
line is evaluated to the special Float which calls itself "1.#INF".

Putting:

    Processor sleep: 0.

between the two lines restores the behaviour I expect.

It's reproducible on W2K or W98 using Dolphin 4pl1, D3 or D2.1.

    -- chris

Chirs

You<[hidden email]> wrote in message
news:[hidden email]...
>
> I think the following's a bug.  Try:
>
>     [10.0 raisedTo: 2222] on: FloatingPointException do: [:err | ].
>     10.0 raisedTo: 1000.
>
> If I execute these lines separately, then the first evaluates to nil, and
> the second throws an overflow exception.  I think that's as it should be.

Indeed.

>
> If I execute the lines in one go, then no exception is thrown and the
second
> line is evaluated to the special Float which calls itself "1.#INF".

Yes, that is a bug. The FPU needs to be reset following the first exception.
The Intel FPU is a strange beast - e.g. depending on the instructions used
exceptions reporting a fault are deferred until the next FP instruction
executed. I'm somewhat surprised that the exception is suppressing the next
one so I'll have to check why that is. In the meantime a workaround is to
insert 'Float reset' in the exception trap. A more permanent patch is to put
the same expression at the top of ProcessorScheduler>>fpException:

> Putting:
>
>     Processor sleep: 0.
>
> between the two lines restores the behaviour I expect.

The VM resets the FPU when it switches processes, in addition to changing
the exception mask (Dolphin processes can have different FP exception
masks), is as if 'Float reset' had been done.

> It's reproducible on W2K or W98 using Dolphin 4pl1, D3 or D2.1.

For once this is an issue related to the CPU, so its a relief that it occurs
consistently across all OS/Dolphin combinations :-).

Regards

Blair

Chris / Blair

Just for interest I repeated this on a new box I've just built based around
a AMD Athlon  processor and get the same results.

--
Best Wishes

David
"Blair McGlashan" <[hidden email]> wrote in message
news:98mc25$2m4bs$[hidden email]... and
> > the second throws an overflow exception.  I think that's as it should
be.
>
> Indeed.
>
> >
> > If I execute the lines in one go, then no exception is thrown and the
> second
> > line is evaluated to the special Float which calls itself "1.#INF".
>
> Yes, that is a bug. The FPU needs to be reset following the first
exception.
> The Intel FPU is a strange beast - e.g. depending on the instructions used
> exceptions reporting a fault are deferred until the next FP instruction
> executed. I'm somewhat surprised that the exception is suppressing the
next
> one so I'll have to check why that is. In the meantime a workaround is to
> insert 'Float reset' in the exception trap. A more permanent patch is to
put occurs
> consistently across all OS/Dolphin combinations :-).
>
> Regards
>
> Blair
>
>