Imortis wrote:I have not tried running anything yet. As I said in the first post, I check to see if it will compile. Since almost every part relies on another part, it is hard to find one part I could test without having the whole thing intact.
There are two approaches you could follow to test your code before you're translated everything:
1st: only translate the parts that are needed to link to minimal testcases
2nd: link against the C versions of all those modules you haven't translated yet. This is pretty easy; you don't need to use FB's makefile to compile the rtlib.
As for dependencies, yes there are plenty from the initialisation code to other parts, but it's actually not that bad: the rtlib is mostly specifically organised to minimise the number of modules that need to linked if they aren't used. So you don't need that much of the rtlib. On my system, compiling an empty .bas file 'print "hello world"' produces a 22.8 kB byte binary (which is stripped). Compiling an empty "int main(){return 0;}" C file is 5.9 kB stripped. libfb.a is 5894 kB (516 kB when stripped), and linking all of libfb.a into the binary using ld's --whole-archive option and then stripping results in 185 kB bytes (...rather odd). So hello-world pulls in < 10% of the rtlib. If you check, you'll find that what gets pulls in is mainly the init code, console stuff like dev_scrn_init.c, core string functions, and locking/unlocking.
As for the integer/long thing, I was originally doing everything that way, but thenfound that we have functions that, in FB, return an integer and in the library code also return a C integer (such as CVI). I went back and changed them all back to Integer.
That's because calls to fb_CVI are never emitted by the compiler. CVI doesn't even exist in the compiler's list of rtlib functions. fb_CVI only exists in the rtlib in case you're linking to object files produced by an ancient version of fbc - it could just be deleted. The comment in front of fb_CVI notes that it's obsolete. So if you keep fb_CVI, it doesn't actually matter whether it returns long or integer, but returning long is more consistent.
Do you have any other examples aside from CVI?
You do have to use long instead of integer.
I did not set Extern C as most function use FBCALL (STDCALL).
...
I probably did not need to use FBCALL either, as that is freeBASIC's default, but my current goal is to convert the code as is, and work on making it work/better later.
FBCALL is only STDCALL on x86 Windows, XBox and cygwin. It's CDECL everywhere else.
You still need EXTERN "C". STDCALL only changes the calling convention, while EXTERN "C" also prevents symbols from being capitalised (equivalent to using ALIAS).
Numerous functions in the rtlib which are called from emitted code, such fb_CHR, aren't FBCALL. I don't know why some are FBCALL and some aren't. But you will have to keep all the FBCALLs. If something isn't FBCALL, it isn't immediately obvious whether it needs to CDECL or it just doesn't matter. But since you'll need EXTERN "C" anyway, there's no need to mark them as CDECL.
