🚀 go-pugleaf

Answer to Peter Moylan, peter@ee.newcastle.edu.au.

Thanks for sharing your experiences that, in deed, go deeper into the
problem than mine.

Some more thoughts just to keep things boiling.

How about using the call(standard_float=>on) in some manner? It will
use the stack model for the 8087 but has to be used in the complete
program. It may fix the problem completely or the Borland DLL problem.
I tried to use stack calling and sandard_float but I lacked a library
(I hope I can find it on the TechKit disk so I'll try again).

Otherwise, to use a Borland DLL it would be needed to clear the TS way
of using the 8087 temporarily (like storing the stack and the status
bits) and then restore it again after the call since it seems to be only
when calling MATHLIB functions there is an error and not in the actual
code generation for a+b/c etc.

Has anybody used the TS Pascal compiler? It has some compatibilty mode
with Borland, maybee that can be used to create a Borland-friendly DLL
interface?

How about remaking the MATHLIB as a DLL? That seems to be one option
when remaking the libraries. The code will be slightly different and
may solve the probem. I am fortunate to have a well tested DOS version
to compare with so I'll know when it works. Anybody tried that?

Windows API have functions _FPInit and _FPTerm that should be used in a
DLL that does not itself init the FPU and install an exception handler.
Probably playing with these makes things even worse.

I may try some of the above but, fortunately, the bug does not stop me
developing further and there are still holes to fill in.


Peter says--------

coprocessor when compiling.  Of course this would hurt the
run-time efficiency.
------------------
I must use floats, and under Windows the Windows FPU emulator runs or
the real one so I can't force to use the emulator only. Under Windows
you can force that you must have an FPU to run the program but the
TopSpeed code then locks some machines.


Peter says--------
The only good solution, I believe, would be to rewrite parts
of the TopSpeed floating point libraries.  This could be a
very major job.
------------------
The CoreMath.a is available but not the compiler itself of course.
If the problem can be fixed inside of that module, it would be the
best solution. I have already had an offer from someone to look into
the code. With some joint effort we may be be to solve it. However,
if I am the only one writing with TS for Windows the interest may be
more of an academic nature. 

Peter says--------
Do you have any information that says that they (TS) will in fact
produce new compilers?  I don't want to throw away TopSpeed, but
I'm not very interested in any upgrade which requires me to buy
Clarion and/or which requires me to run Windows.
------------------
Same here. Mostly I have been treated well by those I have talked
to at TS. I know that some of them would like to go more for the
compilers but the word is out that Clarion is to be the money-maker
and then there may be a go for the compilers. Something like next
year...


The best option now is StonyBrook (some Oberon compilers may come
too now that 32-bits are (almost) here). I am sure StonyBrook have
been good all the time but it is always easier to remain with the
same compiler. The info I got on the StonyBrook compiler makes me
belive it is will be very capable. This was a personal info to me
upon request on differences frm TS so I will not provide any more
details, you have to trust me that it looked good. I don't know what
their official papers say. It is said to be available in Oct or so.


--------------------------------
Bengt-Inge Dalenback, CATT
also at: 
Department of Applied Acoustics
Chalmers University of Technology
Gothenburg, SWEDEN
e-mail: bid@ta.chalmers.se
fax : +46 31 145154