jonas at zeus.rug.ac.be
Fri Mar 30 10:43:39 CEST 2001
On Friday, March 30, 2001, at 03:16 AM, Rich Pasco wrote:
> You guys are the implementers, I'm an end-user. If you can't extend the
> FPU stack in RAM, then you should save and restore its contents on every
> procedure call. Yes, I know it's slow, but it may be the only way to
> correctly handle recursion.
I think the text you forwarded seemed to be geared at OS designers, not compiler designers.
> At the very least, a different Run Time Error code should be reported
> for FPU stack overflow than for other arithmetic faults (divide-by-zero,
> etc.) To lump everything into 207 makes it very hard to diagnose the
We do differentiate between different FPU errors. 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)r.
The stack and the heap reside in the same memory space, with the stack starting on top and growing down and the heap starting at the bottom and growing up. If the stack grows into the heap, you get a stack overflow. In most modern OS'es this is impossible nowadays, because they detect this somehow and grow the available stack space (this last paragraph is not 100% correct I think, but it should give you a general idea of the issues at hand).
More information about the fpc-pascal