Linking with -lmieee in a shared library

[LuigiThirty]

I'm porting a matrix math library I wrote to Amiga for something I'm working on. I want to install it as a shared library. I'm writing it in C and using it from a program written in ASM. I'm using VBCC and the CLib37 example code from Aminet.

I know I need to link it with -lmieee to use the Amiga native floating point libraries but since compiling as a shared library doesn't bring in the C runtime, I've got a problem where compiling it ends up with undefined reference errors.

vc -nostdlib -lamiga -lmieee -cpu=68020 -fpu=68882 -o matrix.library obj/StartUp.o obj/LibInit.o obj/SampleFuncs.o obj/matrix.o
\amiga-dev\targets\m68k-amigaos\lib\mieee.lib(math/math_ieee/_mieee.c): In "__INIT_1_mieee":
Error 21: \amiga-dev\targets\m68k-amigaos\lib\mieee.lib(math/math_ieee/_mieee.c) (CODE+0x7a): Reference to undefined symbol _exit.
Error 21: \amiga-dev\targets\m68k-amigaos\lib\mieee.lib(math/math_ieee/_mieee.c) (CODE+0x9e): Reference to undefined symbol _exit.
Error 21: \amiga-dev\targets\m68k-amigaos\lib\mieee.lib(math/math_ieee/_mieee.c) (CODE+0xc2): Reference to undefined symbol _exit.

How can I get around this so the C floating-point routines point at the Amiga routines?

[LuigiThirty]

Nevermind, I just added an _exit() that gurus if the fp library crashes and it's happy now.

[matthey]

Please remove the "-fpu=68882" when "-lmieee" is specified.

Originally Posted by vbcc.pdf

mieee.lib

This one uses the C= math libraries. The startup code will always open
MathIeeeSingBas.library, MathIeeeDoubBas.library and MathIeeeDoub-
Trans.library. Float return values are passed in d0, double return values are
passed in d0/d1. A 68000 is sufficient to use this library. You must not specify
-fpu=... when you use this library.

http://server.owl.de/~frank/vbcc/docs/vbcc.pdf

[LuigiThirty]

Yeah, I saw that too. I changed out the flags and got it compiling and running with my program



The function names don't appear in Scout but oh well.

[matthey]

Originally Posted by LuigiThirty

Yeah, I saw that too. I changed out the flags and got it compiling and running with my program

Congrats!

Originally Posted by LuigiThirty

The function names don't appear in Scout but oh well.

As I recall, this requires a .fd file for matrix.library and a FD: assign to the location of the .fd files.

[LuigiThirty]

If I fix a bug in the library, is there a way to kick the old version out of memory completely other than rebooting?

[robinsonb5]

Originally Posted by LuigiThirty

If I fix a bug in the library, is there a way to kick the old version out of memory completely other than rebooting?

It's been a while, so I'm not sure about this - but doesn't "avail flush" do just that, provided no applications currently have the library open?

[LuigiThirty]

Originally Posted by robinsonb5

It's been a while, so I'm not sure about this - but doesn't "avail flush" do just that, provided no applications currently have the library open?

Of course, when the application crashes it doesn't free the library. Scout can forcefully free it and then I can flush the cache through WB.

[PeterK]

Originally Posted by LuigiThirty

If I fix a bug in the library, is there a way to kick the old version out of memory completely other than rebooting?

Not sure what you really want to do, but you could call Forbid(), change lib_Node/ln_Name from "matrix.library" into something else like "old_matrix.library", then CacheClearU(), Permit() and load your new patched matrix.library. Of course, this is just some sort of bad coding.

[LuigiThirty]

Here's a question for you. I'm trying to calculate a rotation matrix but I think the compiler is screwing up my floating point format. I'm using the latest vbcc, optimization disabled.

VOID GetXRotationMatrixForOrientation( register __a0 Orientation *o, register __a1 Matrix44 *destination )
{
	FLOAT rad = degreesToRadians(o->rotation.x);
	IdentityMatrix44(destination);
	
	destination->data[1][1] = IEEESPCos(rad);
	destination->data[1][2] = IEEESPSin(rad);
	destination->data[2][1] = -IEEESPSin(rad);
	destination->data[2][2] = IEEESPCos(rad);
}

I debugged this and found that the calculated value for rad is correct along with the retrieved o->rotation.x. The generated code for the first call to IEEESPCos though is:

_GetXRotationMatrixForOrientation
	sub.w	#16,a7
	movem.l	l42,-(a7)
	move.l	a0,a3
	move.l	a1,a2
	move.l	(12,a3),d0
	jsr	_degreesToRadians
	move.l	d0,d1
	move.l	d1,d2
	move.l	a2,a0
	jsr	_IdentityMatrix44
	move.l	d2,-(a7)
	jsr	__ieees2d ;<-- ?
	movem.l	d0/d1,-(a7)
	jsr	_IEEESPCos

If I'm reading it correctly is converting the argument to IEEESPCos to a double-precision value when the function takes a single-precision value. That's weird. Is there something I'm missing that's causing it to use double-precision? I'd rather not hand-write these routines in ASM if I don't have to. All struct values are FLOAT type which according to the headers is a 32-bit long, not a 64-bit value.

edit: A new vbcc was just released this week actually! I upgraded to it and now the generated calls are all given single-precision operands. The numbers I'm getting back at least make sense now! Still need to do some debugging to figure out why they're not right though.

[LuigiThirty]

Hey, I got it working! Other than an FOV issue (it's extremely fisheye) and no clipping so if a line goes out of the screen coordinates it trashes chipmem.

https://twitter.com/LuigiThirty/stat...28868772380673