Assignment of overflow

I found the following strange behaviour while porting Didier Besset's
numerical precision code to Dolphin:

[1]
I was trying to catch the under and overflow exceptions like this:

    largestFloat := 8.98846138827715e+307.
    [largestFloat * 10] on: FloatingPointException do: [:e | nil]
"should it be ...[:e | e exit: nil] ??"

but strangely the code "executes" silently, but "displays" as a
Floating_point_error:_Overflow dialog.


[2]
Executing an overflow assignment stores an unpredictable result...

    largestFloat := 8.98846138827715e+307.
    v1 := largestFloat * 10.        "execute it"
    v1                                        "display it"  "get a different
value each time you evaluate the line above!"


But "displaying" the assignment opens a error dialog...

    largestFloat := 8.98846138827715e+307.
    v1 := largestFloat * 10.        "display it and get a walkback"


[3]
Opening the walkback...

ProcessorScheduler>>fpException:
[] in ProcessorScheduler>>vmi:list:no:with:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>vmi:list:no:with:
SmallInteger(Object)>>doesNotUnderstand:
SmallInteger(CRTLibrary)>>_gcvt:count:buffer:                "What is a
SmallInteger doing here??"
Float>>printOn:significantFigures:


[4]
The same behaviour for underflow!


Ricardo,
[hidden email]

Ricardo

You wrote in message news:9fihvv$41lpm$[hidden email]...
Ah, there is an error in the VM. The X86 FPU raises FP exceptions on the
next FP operation after the one that caused the problem. The VM primitives
are generally coded to avoid this strangeness, but I think an FWAIT
instruction is missing after the FSTP which saves down the result of the
multiplication. The oddity here is that it is the FSTP which overflows, not
the FMUL, and since there are no further FP instructions after the FSTP, the
exception won't be raised until the next FP operation is performed. To test
this out try:

     largestFloat := 8.98846138827715e+307.
     [largestFloat * 10. 1.0 + 1.0] on: FloatingPointException do: [:e |
nil]

You should find an FP exception is then raised. This is recorded as defect #
257, and has been fixed for the PL3 which will be available shortly.

Regards

Blair

Hi Blair,

> You should find an FP exception is then raised. This is recorded as defect
#
> 257, and has been fixed for the PL3 which will be available shortly.

Thanks, as always, for your quick resolution of this problem.  One question:
will the patch replace the VM?  I'm asking so I'll know whether to update my
installers.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> > You should find an FP exception is then raised. This is recorded as
defect
> #
> > 257, and has been fixed for the PL3 which will be available shortly.
>
> Thanks, as always, for your quick resolution of this problem.  One
question:
> will the patch replace the VM?  I'm asking so I'll know whether to update
my
> installers.

We *could* make the patch update the VM but it's a little tricky and liable
to cause probelms. Hence we probably won't distribute the VM via the patch
but suggest that people who want this particular fix (and I think one other
that needs a VM change) download the PL3 MSI file and re-install.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com

---
Visit the Dolphin Smalltalk WikiWeb
http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm
---

Andy,

> We *could* make the patch update the VM but it's a little tricky and
liable
> to cause probelms. Hence we probably won't distribute the VM via the patch
> but suggest that people who want this particular fix (and I think one
other
> that needs a VM change) download the PL3 MSI file and re-install.

Got it!  There will be a new VM, and the patch won't install it.  That's
fine by me; no sense in pressing our collective luck on tricky patch.  After
a reinstall, I'll update my runtime installers.

On other fronts, the download page worked fine for me today, and the D4
setup even prompted me to reboot, which IIRC, it wasn't doing before.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]