[fpc-pascal]Double-precision recursion

[Rich Pasco]

Marco van de Voort wrote:

> Are you certain that GPC does it this way? Or does it just forget about
> optimalisations, and just generates slow code?

I know nothing of GPC.  It was Johan Blok who mentioned GPC.

> How? My main concerns are:
> 
> - Disabling it all together results in severe loss of speed in FPU apps,
> sacrificed for the rare recursion-with FP case.
> 
> - Recursion is not flagged as being recursive. Auto recursion can be
> checked (calling itself), but a perfect solution is hard.
> 
> - Extending FPU stacks might not be possible from user mode under most
> OSes. Did you actually check that GCC does this?

No, again I know nothing of GPC.

To me, correct operation on all programs is better than fast operation
on some but total failure on others.  How about a compiler option switch
so we can choose what we want?

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.

Note: It might be possible for the compiler to look for a function that
directly calls itself, but in the example I provided where there are a
pair of function calling each other alternately, this test would fail
to detect the recursion.

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
problem--it took me three days and a post to this list to figure this
one out with only a "floating point exception" to go on.  If it had
said *which* floating point exception (e.g. FPU hardware stack overflow)
then I would have been much sooner on my way to solve the problem.

     - Rich