🚀 go-pugleaf

In article <42mhgl$jfd@nyheter.chalmers.se>
           bid@ta.chalmers.se "Bengt-Inge Dalenbck" writes:

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

Sounds similar to a problem I once had with FOR loops in OS/2 IOPL code.
I've had a quick look at coremath.a and noemul.a and have a tentative
explanation - sorry I don't have time to try any experiments.
Standard DOS code for Sin goes on the stack something like this
	BP		____  BP set to point here
	reserved	      -2
	CX		      -4	
	AX		      -6
		where fstsw [BP][-2]  will store into "reserved"

The Windows version calls an external routine __FloatStoreSW() in noemul.a
The only thing that seems to be wrong is that it doesn't issue an
fwait to sync the NDP & CPU before reading the value in [BP][-2]
(This routine has it's own temporary copies & returns result in AX)
Whilst this might give the wrong answer sometimes, I can't see 
how that would mangle the stack or the for loop variable.

There is some evidence of panic measures inside the (*%T _WIN*) code
with attempts to preserve AX only to use it again for the same value.
Since the code appears to preserve all the registers it uses, 
I think it's most likely that something is trashing the stack.

FWIW The OS/2 compiled version of mathlib seems to work OK. 
There is a bug in the initiallisation of the x87 rounding rule 
in threads which causes TRUNC() to give the wrong answer (fixable).

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/