Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!csun!news
From: swalton@solaria.csun.edu (Stephen Walton)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Lattice vs. Aztec C what of it?
Message-ID: <1990Dec22.060534.29034@csun.edu>
Date: 22 Dec 90 06:05:34 GMT
References: <9012161351.42.13@INSIDER> <7322@sugar.hackercorp.com> <1990Dec20.231335.14446@csun.edu> <1990Dec21.032913.8163@mtiame.mtia.oz>
Sender: news@csun.edu (News Administrator)
Reply-To: swalton@solaria.csun.edu (Stephen Walton)
Distribution: comp
Organization: Cal State Northridge
Lines: 25
In-Reply-To: jep@mtiame.mtia.oz (Jesper Peterson)

In article <1990Dec21.032913.8163@mtiame.mtia.oz>, jep@mtiame (Jesper
Peterson) writes that he's had sharable library problems as well.
There are (at least) two bugs in the code generated for a sharable
library with 5.0d and both have been reported to Manx.

The first is that if a sharable library function takes no arguments,
no call to geta4() is generated, but a4 is still popped off the stack.
The workaround is to give each of your functions an argument, even
if it isn't used.  I do something like:

void MyLibRoutine(int);
#pragma amicall(MyLibBase, 0x1e, MyLibRoutine(d0));
void MyLibRoutine(int x) {
...
}

which does the right thing even if x isn't looked at in MyLibRoutine.

The other I just found, and occurs only if optimization is turned on.
I have one case which trips it, but haven't got the bug fully
characterized.  I'd simply recommend not optimizing the actual entry
points into your library, but optimizing the lower-lying routines.
-------------------------------
Stephen Walton, Dept. of Physics & Astronomy, Cal State Univ. Northridge
   I am srw@csun.edu no matter WHAT the stupid From: line says!