LeeJ at logica.com
Fri Mar 30 19:39:15 CEST 2001
We seem to have had similar discussion re fp before in the contecyt of fpu
optimisation- or was it different? My 0.001 euro then (& now) was why can't
we fix is as described (IMO this should be done ASAP because it is a REAL
(tho' obscure) bug!). My concern is that if it impacts performance (& this
is quite a big fpc plus point) could we disable it somehow for those who
want max performance & can take a chance on errors...
From: Rich Pasco [mailto:pasco at acm.org]
Sent: Friday, March 30, 2001 03:59
To: fpc-pascal at deadlock.et.tudelft.nl
Subject: Re: [fpc-pascal]Double-precision recursion
> We already have a bug report about this
(<http://www.freepascal.org/bugs/showrec.php3?ID=1269>). We discussed it and
while it will seriously slow down any FPU calculations involving function
calls, the only solution is to save everything on the FPU stack to memory
before calling any procedure. We will fix it this way, but until now no-one
has gotten around doing it.
Thanks for this. Please allow my request to increment the priority
level a notch. :-)
> BP has the FPU stack overflow bug (it even contains a demo program to show
it, indicating that back then they thought the programmer was responsible to
work around this silly implementation of the 80x87 FPU)
Indeed, thanks to this comment, I found the demo (with the default BP
installation path) at C:\BP\EXAMPLES\DOS\FIB8087.PAS
> I think the text you forwarded seemed to be geared at OS designers, not
Perhaps, but if the OS doesn't fix it, then the compiler should include
a work-around when the target platform is vulnerable.
> We do differentiate between different FPU errors.
Thank you for this information. I stand corrected, with due apologies.
> However, RTE 202 refers to a regular stack overflow, not to an FPU stack
overflow (afaik there is no separate RTE defined for an FPU stack overflow
in Delphi nor in TP). That's because they are two completely different
beasts: the FPU stack are 8 hardware registers accessible as a stack inside
the 80x87 FPU. The normal stack is in regular RAM and is like a stack which
you would implement in Pascal as an array on the heap (but starting at the
end of the heap and growing downwards).
I understand this. I believe that it was Johan Blok who was confused on
fpc-pascal maillist - fpc-pascal at lists.freepascal.org
More information about the fpc-pascal