Pure FB Runtime Library (in progress)

User projects written in or related to FreeBASIC.
Post Reply
Imortis
Moderator
Posts: 1923
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: Pure FB Runtime Library (in progress)

Post by Imortis »

Just checking in to let people know I am back at this again finally. I am pulling the newest changes to the RTLIB in as well. I will be re-doing a lot, maybe all, of the string functions as I messed something up in the initial conversion and I have no idea what it was.

This has been a fantastic learning experience for me and I am excited to keep it going.
PaulSquires
Posts: 999
Joined: Jul 14, 2005 23:41

Re: Pure FB Runtime Library (in progress)

Post by PaulSquires »

Hi Imortis, just curious if you are still plugging away at this awesome project?
Imortis
Moderator
Posts: 1923
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: Pure FB Runtime Library (in progress)

Post by Imortis »

PaulSquires wrote:Hi Imortis, just curious if you are still plugging away at this awesome project?
Yes, just much slower. My old job afforded me a good bit of free time in which to work on other projects. My current does not.
PaulSquires
Posts: 999
Joined: Jul 14, 2005 23:41

Re: Pure FB Runtime Library (in progress)

Post by PaulSquires »

Thanks Imortis - I know exactly how you feel. My job also prevents me from devoting long stretches of time to my projects.
Imortis
Moderator
Posts: 1923
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: Pure FB Runtime Library (in progress)

Post by Imortis »

I have updated the make file and a few files in the github to allow it to compile with it's current bugs, if anyone wants to take a look.
https://github.com/ImortisInglorian/fbrtLib
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Pure FB Runtime Library (in progress)

Post by coderJeff »

I've made some updates to fbc/master branch (what is currently fbc-1.09) to help build this library.
- added an 'fbrt' target to fbc's main makefile
- add fbc '-z fbrt' command line option to link the new library instead of old

Refresh your fbc development build and have a newly built fbc compiler in your development tree.
Next, to get the library, be sure to clone in to src/fbrt
From your fbc repository clone directory:
$ git clone https://github.com/ImortisInglorian/fbrtLib src/fbrt

To compile the library (with the standalone build) using fbc's makefile
$ make fbrt ENABLE_STANDALONE=1

The 'fbrt' makefile target does not automatically get built with any other targets.

A few files still need to be translated (for win32):
thread_self.bas
signals.bas
static/fbrt0.bas
Plus many other files for the other platforms.

To note, I have only tested the standalone build on win32 with -gen gas. Also, may have a few bugs to work out of the makefile. I haven't tested the normal build, other platforms, 64-bit, etc.
adeyblue
Posts: 299
Joined: Nov 07, 2019 20:08

Re: Pure FB Runtime Library (in progress)

Post by adeyblue »

I've had a bit of time so I did signal (as far as Windows is concerned). I notice there's been a few commits since the last post here, so is that all of Paul Squires' comments in the Issues checked, or where are we?

I also noticed the TODO's referring to how the TLS used to work and how FB isn't really suited for a 1:1 translation even if it is possible. So if we're using FB to write it and its now the direct translation is pretty much done, let's use FB mechanics rather than aping C's limitations. Thus I've started redesigning how it works internally, using objects and such.

Essentially I have IDEAS (TM) like:
Adding this to dir.bi

Code: Select all

Type DirIterator Extends Object
    Declare Virtual Destructor( )
    Declare Virtual Function Next( ) As String
    '' Can for and step etc be virtual? cos them too
End Type

Declare Function DirCreate( pathFilter As String ) As DirIterator
And then the runtime implements

Code: Select all

'' windows
Type Win32DirIterator Extends DirIterator
   '' ... FindFirstFile et al
End Type

Function DirCreate( pathFilter As String ) As DirIterator
    Return New Win32DirIterator( pathFilter )
End Function

'' *nix
Type PosixDirIterator Extends DirIterator
   '' ... opendir et al
End Type
So then while the original DIR exists and works, It's also possible to have more than one in-flight at a time and the iteration isn't tied to a specific thread etc. And the best thing is that 95% of the code already exists. Relatively simple wins like that for a tentative start.
adeyblue
Posts: 299
Joined: Nov 07, 2019 20:08

Re: Pure FB Runtime Library (in progress)

Post by adeyblue »

Things I've learned building this so far
- Make will silently ignore files with the same name in different directories
- Having the same function with the same prototype (and external linkage) but different bodies defined in separate objects is apparently fine for building the lib? You'd think ar or ld or whoever would complain about that
- a 'treat warnings as errors' option for fbc would be really handy right about now, that or I'm dumb and can't find what the option is

Anyway, I've done the initial changes and it seems ready to be checked and tested. It builds without (additional) warnings and I've managed to run the thread_self test succesfully in 32 & 64 so it's not completely diabolical. It does touch 10% of the files though so it might step on some toes but it does address all the current thread-y todos and fixmes
https://github.com/ImortisInglorian/fbrtLib/pull/15
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Pure FB Runtime Library (in progress)

Post by coderJeff »

Which makefile are you using? I didn't have much luck with the fbrt makefiles.

What I did with the fbc project makefile:
- 'make fbrt' builds src/fbrt/*.bas and ignores the makefiles in src/fbrt
- first build all src/fbrt/obj/<target>[/mt]/*.o object modules
- then merge in missing object files from src/rtlib/obj/<target>[/mt]/*.o
- creates the libraries in lib/<target>/libfbrt[mt].a
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Pure FB Runtime Library (in progress)

Post by coderJeff »

adeyblue wrote:- a 'treat warnings as errors' option for fbc would be really handy right about now, that or I'm dumb and can't find what the option is
heh, I just added that to fbc-1.09.0 this weekend for something I was doing. Pass '-w error' to enable. Let me know if it's bugged. :)

Compiler Option: -w
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: Pure FB Runtime Library (in progress)

Post by caseih »

adeyblue wrote:Make will silently ignore files with the same name in different directories
Sometimes it will, other times it won't. There is a workaround, though. https://stackoverflow.com/questions/117 ... -directory
adeyblue
Posts: 299
Joined: Nov 07, 2019 20:08

Re: Pure FB Runtime Library (in progress)

Post by adeyblue »

coderJeff wrote:Which makefile are you using?
The one that comes with it. I just followed the instruction in the post above mine

I had to add some extra files to the BLACKLIST because UByte Ptr and strcpy, strcat etc in some of the str_conv_ and dev_ files didn't compile. I can't tell you which files now because I reverted the makefile before committing.
adeyblue
Posts: 299
Joined: Nov 07, 2019 20:08

Re: Pure FB Runtime Library (in progress)

Post by adeyblue »

I'm going through all of Paul Squires comments in the issues, that's going to make me Imortis' best friend as I dump another massive PR on him fixing them.

The lack of a direct replacement for C's logical not operator has proved to be a nuisance. Not() by itself doesn't really work when all sorts of functions return longs valued 0 and 1. And Not(CBool()) is just no.

Doing this, the current thing I'm wondering how it came to be the solution, is every function that takes a fbstring having to clean it up if its a temporary one. Obviously there were reasons, but it seems weird that at some point the compiler knew enough to emit their creation, but couldn't then emit their deletion afterwards.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Pure FB Runtime Library (in progress)

Post by coderJeff »

adeyblue wrote:how it came to be the solution, is every function that takes a fbstring having to clean it up if its a temporary one.
Early on before objects, managing temporary string lifetimes in the rtlib instead of the compiler. Like where results of one string function are passed into another rtlib or user function. 'var s = func( trim(lcase(left(s, instr(s,"=")))) )' -- or whatever.

I'm sure it's been on the todo list for 10+ years.
todo.txt wrote:[ ] All functions returning STRING should actually return the FBSTRING object
- it must be coded in plain C to avoid C++ dependencies
- compiler has to allocate the descriptor as it does now following the gcc ABI
- any function in the run-time library returning strings will have to be
modified (chicken-egg problem)
- allocated on stack instead of using temp descriptors,
- better with threads, as no more locking needed in the rtlib
- allows STRING results to be passed between multiple rtlibs without
memory leaks (e.g. returned from DLL)
- no more STR_LOCK's
- no more checks for temp descriptors in all rtlib procs taking STRINGs
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Pure FB Runtime Library (in progress)

Post by counting_pine »

adeyblue wrote:The lack of a direct replacement for C's logical not operator has proved to be a nuisance. Not() by itself doesn't really work when all sorts of functions return longs valued 0 and 1. And Not(CBool()) is just no.
The compiler tends to use (… = False), I think.

Note that it’s not a great idea to use syntax like ‘Not(x)’ in general, because it doesn’t work like a function and can mislead expectations about operator precedence. e.g. ‘Not(a) <> b’ is equivalent to ‘Not ((a) <> b)’.
Post Reply