🚀 go-pugleaf

Bengt-Inge DalenbŠck (bid@ta.chalmers.se) wrote:
>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 ***

I don't know how to fix this problem, but perhaps I can give some
insight into what's going on.

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

[snip]

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

This sounds very much like a problem I had (and still haven't solved)
when trying to link TopSpeed modules with Borland C modules.
The problem arises because the coprocessor registers can be used
in two distinct ways: as a bank of numbered registers, or as a
stack.  The first approach is superior in terms of code optimisation,
but can be very confusing because of some hardware quirks.  (Certain
operations inevitably affect the top-of-stack pointer, and this
changes the way the hardware interprets register numbers.)  The
"stack" approach is more consistent with the way the hardware works,
and therefore easier to get right, but it does mean that you get
inferior object code because you're failing to take advantage of
being able to leave some intermediate results in the floating
point registers.

Borland compilers use the "stack" approach, and in general they
adopt the rule that all procedures must clean up the stack before
they return.  (Except for a function that returns a floating
point result on the top of the stack.)  TopSpeed does better
code optimisation by using the "register" approach, but this does
mean that the TopSpeed code leaves stuff sitting in registers
after it's no longer needed.  After a sufficiently long chain of
floating point operations, this unused rubbish either gets popped
off the top of the stack, or gets overwritten when the register
gets used for something else, or (more likely) gets pushed through
the bottom of the stack (and therefore lost because in reality
the stack is circular).

Another difference between Borland and Pascal is in their settings
of the hardware error masks.  Certain things cause error interrupts
in one case but not the other, and this is related to the
stack/register bank dichotomy.

The bottom line is this: everything seems to work OK if all of
your code is Borland-generated code, or if all of your code is
TopSpeed-generated code (the language doesn't matter); but if
you try to combine the two then a spurious "stack overflow"
error will eventually occur while you're executing the TopSpeed
code.  The precise cause of the error is difficult to determine
because of the way the coprocessor hardware works: the error
interrupt happens when you're already some way past the point
where the error was triggered.  What seems to be happening is
that a stack overflow is caused by loading a floating point
number when the stack is already full, and the stack is full
because of some left-over rubbish that has been gradually been
pushed deeper and deeper into the stack.  Logically this isn't
an error at all - all that's happening is that you're losing
the contents of a register that you weren't using anyway - but
the hardware detects it as an error because it thinks that the
register at the bottom of the stack is still in use.

In part this is a consequence of the fact that we're using the
stack the TopSpeed way but enabling the error flags the Borland
way, but I think there's also a deeper problem: a bug in the
TopSpeed floating point code generation that sometimes creates
a redundant stack push.  This bug is harmless in most situations,
but fatal if you try to mix Borland and TopSpeed code.  I'm not
sure whether the bug is confined to the core libraries, or is
also occurring in the compiler's code generator.

I've never tried to use TopSpeed with Windows, but I suspect that
pretty much the same problem is the cause of problems when
working under Windows.

A possible fix would be to specify that you don't have a 
coprocessor when compiling.  Of course this would hurt the
run-time efficiency.

The only good solution, I believe, would be to rewrite parts
of the TopSpeed floating point libraries.  This could be a
very major job.

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

I think the above two are the source of the problem.  Furthermore
I don't think you can fix the problem merely by changing pragma
settings - I've already tried all of the combinations I could
think of.

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

I don't think language is an issue.  The problem occurs with
both TopSpeed Modula-2 and TopSpeed C.  The compilers use the
same back end, and pretty much the same libraries, though there
are some differences in terms of libraries.

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

Do you have any information that says that they 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.

--
Peter Moylan                       peter@ee.newcastle.edu.au
                           file://ee.newcastle.edu.au/pub/www/Moylan.html