🚀 go-pugleaf

Hi all,

   Now, after having ported a comparatively large project from TopSpeed
3.10  to Windows 3.1 (merging 30 Xtd, and large model programs to one
MDI app), I can report the following.

   Once you get the hang of it (and have fixed some things reported in
my earlier longer postings half a year ago) it all works very well!

   *** Except for one thing ***

   MATHLIB has a problem if e.g. Sin() or, for what it seems, any other
 MATHLIB function is called repeatedly in a loop. In such cases a 
register is trashed (the one used for the loop variable) and the loop 
is terminated prematurely. However, if MATHLIB functions are called one
at a time in the middle of the code it all works fine, and even after
an huge amount of flotating point calculations (and I mean hours worth
of it) the final results are identical to the Xtd DOS program's (also
the speed is nearly identical). If debug is turned on the problem
disapears since the code then changes but of course the execution
speed also goes down, and I can't have that.

   So, what to do? In the FIXES.DOC document at the UK BBS there is
*one* problem mentioned with Windows and floats. That did not help.

   So, then what to do? I stripped down the code and sent a very simple
program to TopSpeed and they recognized the bug. And, hold your hats,
I received a bugfix! Good news! Well, not quite. After a rebuild of the
libraries it still did not work (also that was recognized by TopSpeed
but no more help to get). It has something to do with which registers
are preserved and not by CoreMath.a under Windows. I don't know enough
assembler to sort it out myself. I know this group has several that
know more low-level ("TopSpeed and assembler" thread...).

  So, then what to do? I wrapped all the MATHLIB functions in a DLL and
that obviously changed some function prologs (or whatever) so that it
worked - almost. Now in some very few cases (but still too many...) I
get strange results and e.g. the Str.RealToStr does not give the
correct results (Str calls MATHLIB).

   So then what to do? I bought Borland Pascal 7.0 to get some more
Windows documentation and planned to make the same DLL using BP instead.
To create a DLL in BP *without* floating point and call it from
TopSpeed works fine, but as soon as I try the real thing with the BP
Double floats (N+ compiler directive that should be the same as LONGREAL),
I get a GPF. Does anybody with a better low-level understanding have
some advice. The low-level docs for BP are thin and the map-file it
generates for the DLL is not much. E.g. I can't spot the WEP or LibMain
procedures (that are suppose to be named exactly like that and WEP is to
be exported in the EXP-file, in BP it is not explicitly exported but
hidden somewhere) but it works anyway to use the DLL from TopSpeed (i.e.
without floating-point). Borland does seem to do things in an
unorthodox manner.

   Some thoughts I have: 

1) Can maybee a LONGREAL be passed differently in BP? From what it seems, 
it is on the stack as it is supposed to be for a DLL (pragma assures
that in the TS DLL DEF-file). Or is the result returned differently? 

2) Can the double float formats be different. Should not be if they both
use the coprocessor 8-byte type? Anyway, it ought not cause a GPF.

3) Is it the init procedures for the math processor that are different
and clashes between TS and BP? I can call the BP DLL from a BP program
without problem but I get GPFs both when calling the TS DLL in BP and
when calling the BP DLL in TS.

4) TS don't use the coprosessor stack but BP does. That should be able
to fix with pragmas but maybe a rebuild of the TS libs are required for
that. I tried some promising prgma settings but no luck since it is
fixed in the LIB anyway.

5) I could create the same DLL with a C-compiler but I may run into the
same problems again if I don't understand the reason.

6) I could make my own versions of some of the math functions if I can
pinpoint the problem functions (not easy to debug since the problem
goes away with debug code on) but that would probably be much slower.

A note: as I am sure you all have experienced, it may be tricky with
DLLs under Windows since if something goes wrong the old DLL may stay
loaded. I am aware  of this so for each error I have had to restart
Windows to clean up (is that a mess, or is that a mess?)

I am sure I can find some kind of solution (a patch rather) to this but
I would much appreciate you low-level guys' opinion on this.

TS will not make any new pure compilers until maybe next year sometime.
You can buy Modula-2 support for Clarion for Windows but it is still the
same old 16-bit libraries were the bugs are not even fixed. It is anyway
a messy solution since I already have the full code in Modula which also
makes it pointless to use e.g. Delphi and TS DLLs at this stage.

I plan to finnish the 3.1 version with TS (it is nearly finnsihed) and
then switch to StonyBrook and  Windows 95 (the information I have on the
new compiler makes it look very very good). October is latest stated
release month.

With hopes of a better future for Modula-2 (-3 and Oberon now when
Windows 95 finally has arrived).

Cheers

 Bengt-Inge

--------------------------------
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