pasco at acm.org
Fri Mar 30 03:16:50 CEST 2001
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.
More information about the fpc-pascal