Pure FB Runtime Library (in progress)

[srvaldez]

will this changes break FB on platforms like arm or macOS ?
I do most of my hobby programming on macOS.

[Imortis]

will this changes break FB on platforms like arm or macOS ?
I do most of my hobby programming on macOS.

It should not break anything. The ultimate goal is to make it work just like the current runtime library.

[srvaldez]

ok, thanks :)

[Imortis]

I just got a new linux distro setup on my laptop. I got FB installed (64bit), and I wanted to try compiling this from there, but I am not sure how to format the "FBC_SRC_PATH" for linux. Everything I have tried just keeps telling me I need to set the FBC_SRC_PATH

[TeeEmCee]

Sorry, haven't been around.

Either you can edit the makefile directly, or you can create a config.mk file and place it next to makefile. (Or, you could even pass it on the commandline every time) I definitely recommend config.mk, because that way git won't see any local changes to makefile

I have fbrtlib cloned at /mnt/common/src/!lang/fbrtLib and FB cloned at /mnt/common/src/!lang/fbc. My config.mk file contains the line

Code: Select all

FB_SRC_PATH := ../fbc/src/

I.e. it should point to the directory containing rtlib.

As for testing it, the rest of my config.mk is:

Code: Select all

prefix := fbc-hybrid
# To skip files, add them to BLACKLIST:
# con_readline.bas crashes fbc
BLACKLIST += ./con_readline.bas
# crt/stat.bi not supported on linux
BLACKLIST += ./file_attr.bas ./file_datetime.bas

(Those BLACKLIST lines are probably obsolete now; I haven't pulled any changed to fbrtlib in some weeks)

I have a directory called fbc-hybrid inside the fbrtLib directory, in which I've copied a full installation of FB (it has subdirectories bin, lib, etc). Then running "make install" copies all the fbrtLib libraries into the fbc-hybrid installation, overwriting the preexisting ones, and I can run fbc from that install to test it. (Warning: PIC libraries are disabled by default in the makefile, so those preexisting ones won't be overridden.)

[Imortis]

I have been rather busy for the last few weeks and have done absolutely NO work on this project in that time. If anyone else wants to pitch in, now might be a good time to do so. I am not sure when I will be able to return to work on this project so it may be stagnant for a while if no one else wants to help out.

[coderJeff]

Hi Imortis, As evident from https://github.com/ImortisInglorian/fbrtLib you have put much time and effort in to the work. Hopefully you will take these suggestions in the most positive way:

Please update README.md to include:
1) what to directory to checkout to?
2) how to build? setting FB_SRC_PATH, etc
3) how to test with current fbc?
4) how to contribute to this work?
5) plan for integration to fbc? Separate project only? Or, new fbc makefile to choose alternate fbrt at build time?

No guarantees, but if you can make the hand-off to others a little easier, it might actually happen.

[Imortis]

Hi Imortis, As evident from https://github.com/ImortisInglorian/fbrtLib you have put much time and effort in to the work. Hopefully you will take these suggestions in the most positive way:

Please update README.md to include:
1) what to directory to checkout to?
2) how to build? setting FB_SRC_PATH, etc
3) how to test with current fbc?
4) how to contribute to this work?
5) plan for integration to fbc? Separate project only? Or, new fbc makefile to choose alternate fbrt at build time?

No guarantees, but if you can make the hand-off to others a little easier, it might actually happen.

Yous suggestions are top notch. I will do so as soon as I have the time. I kinda forgot the README.md was there. Oops.

[Imortis]

I can finally get back to this now. Still haven't updated the readme, but I am working on it. While working through the build process on my machine so I could write it up I discovered a few issues I had missed. Working on that now. Should have the readme updated and hopefully a test lib soon.

EDIT:
I got it to spit out a more or less valid lib, found and fixed an off-by-1 error in my translation because I could test, but now I am getting a really weird error from the SLEEP command. The debugger shows the error as:

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()

Debugging shows me it is crashing a SLEEP call. Any idea what "?? ()" means in this context?

[marcov]

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()

Debugging shows me it is crashing a SLEEP call. Any idea what "?? ()" means in this context?

?? is where the symbol (procedure) name should be, the line number should be in parenthesis. The debugger was not able to find debug/line info for that symbol, so both symbol name and line number are empty (respectively "??" and nothing)

Since the address is 0x00000000 (NULL/NIL), somewhere NIL was called.

[Imortis]

Thank you, sir. You pointed me right at it. My stupid self accidentally made a loop in the sleep command on windows. The WinAPI command for FB was renamed to "Sleep_" and I did not make that change in the fb_Delay() command. It was trying to call "Sleep", which in turn tried to call "Sleep", etc. Stupid mistake.

[Imortis]

HA! Still working on this. Print "WORKS" but I some how managed to shift all ascii chars up one character, starting in the 2nd position, skipping the last char (probably related to starting in the 2nd position) AND not properly escaping newline. Hurray!

Iffmp!Xpsm\n

This is hilarious. I am finally into the fun part of the process.

[counting_pine]

In a related note: one of the things this brings up is that FB itself uses variadic functions in many places inside the RTLib, but the C Emitter (which is needed for 64bit compilation) does not support variadic functions. Either, the C Emitter needs to fix this (difficult as FB and C handle that in very different ways) or a different way of compiling 64bit code is needed (VERY difficult as it would require writing a new emitter entirely).

coderJeff has been working hard on variadic functions recently, so it looks like a complete port of the rtlib to FreeBASIC may actually be possible soon.

[angros47]

I just want to remind that, if main changes are made in the runtime, the file fbc/src/rtlib/dos/symb_reg.txt must be updated, for the dos version, or dynamic linking wouldn't work.

To update it, one has to build the runtime, run the file maksymbr (that will update the file symb_reg), and then recompile the runtime again (for that reason, the operation cannot be automated in the makefile, or it would enter an endless loop)

[Imortis]

In a related note: one of the things this brings up is that FB itself uses variadic functions in many places inside the RTLib, but the C Emitter (which is needed for 64bit compilation) does not support variadic functions. Either, the C Emitter needs to fix this (difficult as FB and C handle that in very different ways) or a different way of compiling 64bit code is needed (VERY difficult as it would require writing a new emitter entirely).

coderJeff has been working hard on variadic functions recently, so it looks like a complete port of the rtlib to FreeBASIC may actually be possible soon.

Yeah. I get emails from all activity on the repo, so I have been watching closely. I have not had the time to work on this much lately, but I hope to get back into it here soon.