compiling for floating point with vbcc: -lmieee or -lm040?

[TheBilgeRat]

I am trying to get up to speed on coding C for the amiga.  I'm using vbcc from the CLI and am trying to figure out which floating point linker I should use if I am coding for my 68040 in my A4000.

Currently, the only one that works properly is -lmieee.  if I flag it with -lm040 it errors out with a bunch of "reference to undefined symbol".

At the moment I'm not doing real intensive floating point operations, but it would be nice and fun if I could use the FPU in the 040.  I am assuming compiling to ieee is using something other than the actual FPU in the processor.

Am I missing a library somewhere?  I do have NDK 3.9 and vbcc pointed at it, but I'm not positive its pointed at it correctly.  I have it aimed at the parent drawer, not any of the directories underneath.  Should it be pointed at the Include drawer?

[Trev]

libm040 should have been in the m68k-amigaos target archive. If it's not in there, drop a message to Frank (PhxAss). Email's probably best.

[Leffmann]

Specify -fpu=68040.

[matthey]

I am trying to get up to speed on coding C for the amiga.  I'm using vbcc from the CLI and am trying to figure out which floating point linker I should use if I am coding for my 68040 in my A4000.

Currently, the only one that works properly is -lmieee.  if I flag it with -lm040 it errors out with a bunch of "reference to undefined symbol".

At the moment I'm not doing real intensive floating point operations, but it would be nice and fun if I could use the FPU in the 040.  I am assuming compiling to ieee is using something other than the actual FPU in the processor.

The -lmieee link library uses the Amiga ieee shared libraries which use the FPU if installed properly. This is much faster than software floating point, follows the IEEE standard very well and should avoid all trapped instructions. Using -lm040 with -fpu=68040 generates 68040 FPU instructions directly in the code. It has the potential to be faster but it does generate some trapped instructions currently (FINT/FINTRZ), has extra precision which is slightly less IEEE compatible (usually the extra precision is an advantage) and has some code quality problems currently (being worked on).

Am I missing a library somewhere?  I do have NDK 3.9 and vbcc pointed at it, but I'm not positive its pointed at it correctly.  I have it aimed at the parent drawer, not any of the directories underneath.  Should it be pointed at the Include drawer?

The vbcc install assigns vincludeos3: which includes the 3.9 includes (other popular SDK includes and probably some minor fixes too). The vincludeos3: assign points to vbcc:targets/m68k-amigaos/include as installed on a 68k Amiga for a 68k Amiga. Link with the vbcc versions of amiga.lib if needed also (not the NDK 3.9 or other compiler versions). It's all assigned and ready to go if you follow the vbcc manual.

Specify -fpu=68040.

Correct. To link with the Amiga IEEE shared libraries, do not specify a -fpu option in the compiler options:

-cpu=68040 (or -cpu=68020 to run on 68020-68060)

and link with:

-lmieee

To use 040 FPU instructions in the code, compile with:

-cpu=68040 -fpu=68040

and link with:

-lm040

There should be a new version of vbcc out soon although the -lm040 will likely not be fully improved yet. The goal is to remove all fp trapped instructions and implement full c99 support in math.h.

[TheBilgeRat]

The -lmieee link library uses the Amiga ieee shared libraries which use the FPU if installed properly. This is much faster than software floating point, follows the IEEE standard very well and should avoid all trapped instructions. Using -lm040 with -fpu=68040 generates 68040 FPU instructions directly in the code. It has the potential to be faster but it does generate some trapped instructions currently (FINT/FINTRZ), has extra precision which is slightly less IEEE compatible (usually the extra precision is an advantage) and has some code quality problems currently (being worked on).

Thanks, matthey!  I probably should have RTM past "do -lm"
BTW, great manual!

The vbcc install assigns vincludeos3: which includes the 3.9 includes (other popular SDK includes and probably some minor fixes too). The vincludeos3: assign points to vbcc:targets/m68k-amigaos/include as installed on a 68k Amiga for a 68k Amiga. Link with the vbcc versions of amiga.lib if needed also (not the NDK 3.9 or other compiler versions). It's all assigned and ready to go if you follow the vbcc manual.

So...when I did the vbcc-target install and it asked for the headers, what should I point that at?  I assumed it wanted to be pointed at some devel set.

Correct. To link with the Amiga IEEE shared libraries, do not specify a -fpu option in the compiler options:

-cpu=68040 (or -cpu=68020 to run on 68020-68060)

and link with:

-lmieee

To use 040 FPU instructions in the code, compile with:

-cpu=68040 -fpu=68040

and link with:

-lm040

There should be a new version of vbcc out soon although the -lm040 will likely not be fully improved yet. The goal is to remove all fp trapped instructions and implement full c99 support in math.h.

Nice!  Well, thanks for the support!  I love vbcc - all in all a great compiler.

[TheBilgeRat]

I think I ran into that doing a simple character counting program with a double.

compiling with just -lmieee and the number count works fine.
compiling with -fpu=68040 -lmieee and the number is NAN.

[matthey]

Thanks, matthey!  I probably should have RTM past "do -lm"
BTW, great manual!

It helps that the manual is easy to read. Telling someone to RTM the GCC manual is rude .

So...when I did the vbcc-target install and it asked for the headers, what should I point that at?  I assumed it wanted to be pointed at some devel set.

It should point to the include/include_h directory of the NDK_3.9. If an updated version of SAS/C is installed with AmigaOS 3.9 includes as was my case, I simply selected the default INCLUDE: for the install. I didn't remember any issues with the fast and easy install and that is why.

Nice!  Well, thanks for the support!  I love vbcc - all in all a great compiler.

Vbcc has great potential. If the 68k code quality surpasses GCC 3.x as I suspect it will, it will be used a lot more. It's becoming more GCC compatible which helps too.

I think I ran into that doing a simple character counting program with a double.

compiling with just -lmieee and the number count works fine.
compiling with -fpu=68040 -lmieee and the number is NAN.

A compiler error would be nice but I don't know how difficult the detection would be. I suspect that inlined assembler code using 68040 FPU instructions and registers is used with the IEEE include code which doesn't use floating point registers (uses data registers). The 2 methods are clearly not compatible.

[Trev]

If I remember correctly, the host environment, i.e. vbcc itself, uses the OS math libraries. If your target math environment is different, keep an eye on precision. Constants and operations generated by the compiler may round differently than bits generated at run time. If you need consistency, test your host environment, and then set the FPU rounding mode appropriatly at program startup.

Edit: You could alternatively build host-specific vbcc executables--one for libs, one for 68881, one for 68040, etc--and then match host to target with e.g. -fpu=foo.