compile problems (vbcc)

[meynaf]

Three problems occured to me while compiling some project :
- There is no strdup function. It's not in string.h as should be, and no .lib contains it.
- Assembler says unknown mnemonic for <inline> and <einline>. New to 0.9f ; version 0.905 did not have this issue.
- Linker complains about missing _nearbyintf symbol. It's available in some fpu libs (like m040.lib), but that does not look like a proper way for building a nofpu version...

[ajk]

I don't think strdup() is a standard function. POSIX maybe?

[ross]

Posix

[meynaf]

So only thing i can do is to find some C implementation of it and add that to the program ?

[ajk]

That's probably easiest. It should only be a few lines of code. Someone on StackOverflow suggest this:

char *strdup (const char *s) {
    char *d = malloc (strlen (s) + 1);   // Allocate memory
    if (d != NULL) strcpy (d,s);         // Copy string if okay
    return d;                            // Return new memory
}

[meynaf]

Ok, done. Now what for the next two problems ?

[matthey]

Originally Posted by meynaf

Three problems occured to me while compiling some project :
- There is no strdup function. It's not in string.h as should be, and no .lib contains it.

The strdup is also in Frank's PosixLib.

http://aminet.net/package/dev/c/vbcc_PosixLib

Originally Posted by meynaf

- Assembler says unknown mnemonic for <inline> and <einline>. New to 0.9f ; version 0.905 did not have this issue.

Strange. I haven't downloaded and installed the new version yet but I thought Frank was going to use the new header files with inline/einline for assembler inlines (in string.h, stdlib.h, etc.). We discussed having them work in -phxass mode of vasm (was default for vbcc) as that would ease the transition to using regular vasm mode but he may have removed this support. I guess I need to install and see.

Originally Posted by meynaf

- Linker complains about missing _nearbyintf symbol. It's available in some fpu libs (like m040.lib), but that does not look like a proper way for building a nofpu version...

Which floating point math lib did you compile/link with? The behavior should be the same for -lm881, -lm040 and -lm060. The -lmieee option uses the C= libraries and is limited by the support they give. The nearbyintf() function/macro uses "fint fp0" using the current rounding mode but the C= ieee libraries have no concept of a rounding mode. Frank was looking into adding a different but better soft floating point library at one point. I also considered creating an Amiga c99fps.library and c99fpd.library as more modern ieee library replacements at one time. The current fp support provides what most people would use as is and there might not even be enough users of a better soft float option to properly test and debug the code.

[meynaf]

Originally Posted by matthey

Which floating point math lib did you compile/link with? The behavior should be the same for -lm881, -lm040 and -lm060. The -lmieee option uses the C= libraries and is limited by the support they give. The nearbyintf() function/macro uses "fint fp0" using the current rounding mode but the C= ieee libraries have no concept of a rounding mode. Frank was looking into adding a different but better soft floating point library at one point. I also considered creating an Amiga c99fps.library and c99fpd.library as more modern ieee library replacements at one time. The current fp support provides what most people would use as is and there might not even be enough users of a better soft float option to properly test and debug the code.

The whole story is : currently trying to compile something for making it work before possible asm conversion/optimization. Said otherwise, it's not my own code to start with so i can't really change its structure (at least not before having made it work).

As it appears to rely heavily on C99 it seems only VBCC will do it - GCC does not work on my setup and is asm unfriendly anyway (no option to output proper amiga asm source).

I wanted to use -lmieee only.
Then the linker complained about nearbyintf (without that function being called explicitly anywhere).
I added -lm040 as the function is there. Noticed -lmieee was still needed so both got linked in.
Then it could finally be built. However it now needs fpu.
I started uae in 040 mode to test results and found out the program does not work anymore (same source code works fine with VS2015).
Currently trying to debug the bloody thing to discover what went wrong (no crash, just bogus data output).

If you tell me i can't have proper nearbyintf implementation without fpu then so be it - better than not compiling at all.

[matthey]

Originally Posted by meynaf

I wanted to use -lmieee only.
Then the linker complained about nearbyintf (without that function being called explicitly anywhere).
I added -lm040 as the function is there. Noticed -lmieee was still needed so both got linked in.
Then it could finally be built. However it now needs fpu.
I started uae in 040 mode to test results and found out the program does not work anymore (same source code works fine with VS2015).
Currently trying to debug the bloody thing to discover what went wrong (no crash, just bogus data output).

Be careful *not* to...

o link code compiled with different math libs (e.g. -lmieee and -lm040)
o specify -fpu=68xxx with -lmieee

There probably should be more tests and error messages for these conditions as the result can compile fine but crash.

Originally Posted by meynaf

If you tell me i can't have proper nearbyintf implementation without fpu then so be it - better than not compiling at all.

As far as I know, nearbyintf() can not be supported as is by the Amiga ieee libraries. It should be possible for a soft float implementation to support nearbyintf() but I do not believe there is any vbcc support for the 68k AmigaOS target at this time.

[meynaf]

Originally Posted by matthey

Be careful *not* to...

o link code compiled with different math libs (e.g. -lmieee and -lm040)

Well, this is what i did because else it refused to link.

Errors should appear if the same function name occurs several times, shouldn't they ?

Originally Posted by matthey

o specify -fpu=68xxx with -lmieee

I didn't specify -fpu...
So it's needed even for 040 ?

Originally Posted by matthey

There probably should be more tests and error messages for these conditions as the result can compile fine but crash.

No crash here, just lrintf not working - always returning 0.

Originally Posted by matthey

As far as I know, nearbyintf() can not be supported as is by the Amiga ieee libraries. It should be possible for a soft float implementation to support nearbyintf() but I do not believe there is any vbcc support for the 68k AmigaOS target at this time.

Isn't this some kind of (int)(floatval+0.5f) or something like that ?

I replaced it with normal cast and it now works. I don't really need "proper" rounding anyway.

[matthey]

Originally Posted by meynaf

Well, this is what i did because else it refused to link.

Errors should appear if the same function name occurs several times, shouldn't they ?

Multiple function calls are fine. The correct support code just has to be found.

Originally Posted by meynaf

I didn't specify -fpu...
So it's needed even for 040 ?

In my experience, -fpu=68040 and -lm040 should be added together.

Originally Posted by meynaf

No crash here, just lrintf not working - always returning 0.

The program is still broken and I believe crashes are possible with what you did.

Originally Posted by meynaf

Isn't this some kind of (int)(floatval+0.5f) or something like that ?

No, the rounding of FINT is variable depending on the C99 fenv (floating point environment) with current rounding settings in the 68k FPU FPCR. If the rounding is known at compile time then a different function or casting should be used as it may be faster.

Originally Posted by meynaf

I replaced it with normal cast and it now works. I don't really need "proper" rounding anyway.

I believe C casting defaults to round toward zero which would be like the FINTRZ instruction.

[meynaf]

Originally Posted by matthey

Multiple function calls is fine. The correct support code just has to be found.

Yes but it was about multiple support code for the same function, i.e. same feature linked from several libs.

Originally Posted by matthey

The program is still broken and I believe crashes are possible with what you did.

A crash would probably have been easier to debug...

[phx]

Originally Posted by meynaf

- Assembler says unknown mnemonic for <inline> and <einline>. New to 0.9f ; version 0.905 did not have this issue.

Works for me. Check your vasm version. You need at least vasm 1.7f to make these directives work (vbcc 0.9f includes vasm 1.8).

Originally Posted by meynaf

No crash here, just lrintf not working - always returning 0.

As matthey already mentioned the implementation of nearbyintf(), which is called for lrintf(), is quite simple and only works for floats between -2147483648 and 2147483647.

Matthey implemented many new C99 math functions and improved present ones, but unfortunately for FPU only (I certainly won't blame him). So I tried to implement a few new C99 functions for softfloat (mieee.lib), but I didn't find the time for all. You can blame me!

[plasmab]

I love vbcc and vasm. But compiling a hello world style C file seems to eat my 4mb of ram up quickly. Any way to make it use temp disk space rather than ram: for temp files?

[meynaf]

Originally Posted by phx

Works for me. Check your vasm version. You need at least vasm 1.7f to make these directives work (vbcc 0.9f includes vasm 1.8).

I used the vbcc 0.9f archive "as is", without touching vasm.

Originally Posted by phx

As matthey already mentioned the implementation of nearbyintf(), which is called for lrintf(), is quite simple and only works for floats between -2147483648 and 2147483647.

Matthey implemented many new C99 math functions and improved present ones, but unfortunately for FPU only (I certainly won't blame him). So I tried to implement a few new C99 functions for softfloat (mieee.lib), but I didn't find the time for all. You can blame me!

Too late to blame you, I did otherwise

[phx]

Originally Posted by plasmab

Any way to make it use temp disk space rather than ram: for temp files?

Try to assign T: to a place on your disk.

Originally Posted by meynaf

I used the vbcc 0.9f archive "as is", without touching vasm.

Any old vasm version somewhere in your path? When the problem persists, please send me something to reproduce it. (Although I'm currently on holiday in Greece, so I probably can't tackle the problem in the next 6 days).

[meynaf]

Originally Posted by phx

Any old vasm version somewhere in your path? When the problem persists, please send me something to reproduce it. (Although I'm currently on holiday in Greece, so I probably can't tackle the problem in the next 6 days).

Somewhere on my normal path no, but it's possible some assign leading to 1.7e was still there. If this was the case then it was using the old compiler as well.

[meynaf]

I have found the sources of vbcc itself but not the sources of the .lib. Where can i find sources for all these .lib (amigaos target) ?
A .s (including compiler output) is more manageable for me than a .lib.

[phx]

The linker libraries are the only parts which are not open source. Volker Barthelmann has no intention to change that, for various reasons.

If you have a specific problem or want to work on parts of the library source, then contact me privately. Maybe we can find a solution.

[Thorham]

Originally Posted by meynaf

while compiling some project

Can I ask which one so I can have a look?