Question about rtlib
Question about rtlib
Can anyone in the know give me a reason why FB's rtlibs SHOULD NOT be re-written in FB? Same with fbgfx? Is is just a case of the amount of time that would take? Any insight is welcome.
Re: Question about rtlib
GCC provides some optimizations that FreeBasic doesn't have, making the code more efficient.
Anyway, rewriting the libraries in FreeBasic would be possible (FreeBasic has all the features of C, and many features of C++, so any C code could be ported in FreeBasic), but it would not give any advantage, since the code would be just as difficult to understand as currently is (having to mess with OS-specific APIs, pointers, and conditional compiling). So, I can ask, in return... is there any reason why FB's rtlibs SHOULD be re-written in FB? I doubt, actually.
Anyway, rewriting the libraries in FreeBasic would be possible (FreeBasic has all the features of C, and many features of C++, so any C code could be ported in FreeBasic), but it would not give any advantage, since the code would be just as difficult to understand as currently is (having to mess with OS-specific APIs, pointers, and conditional compiling). So, I can ask, in return... is there any reason why FB's rtlibs SHOULD be re-written in FB? I doubt, actually.
Re: Question about rtlib
The only problem I see is that it uses lots of POSIX/libc/kernel (Linux, FreeBSD, etc.) system headers, which are not yet available as .bi and are rather hard to auto-translate and maintain in my experience. But since such bindings are missing for FB anyways (including support for multiple libc's on Linux, for example), if they were added, they could aswell also be used for the rtlib/gfxlib.
Also it's ~50k lines of code to convert, which has to be done first (probably lots of it could be automated though, just like header translation).
Also it's ~50k lines of code to convert, which has to be done first (probably lots of it could be automated though, just like header translation).
Re: Question about rtlib
It would greatly simplify the toolchain required to build FBC itself. And, if optimizations are wanted, FBC still has the GCC backend. The code could be run through that for the rtlib and fbgfxlib to get the optimizations.angros47 wrote: So, I can ask, in return... is there any reason why FB's rtlibs SHOULD be re-written in FB? I doubt, actually.
Re: Question about rtlib
It could be a good reason. Although the 64 bit version requires GCC anyway
Re: Question about rtlib
You don't need all of that. A core set is like 200 lines (which is /general/ unix, not just linux), and some structs (DIR, Stat, statfs) etc.dkl wrote:The only problem I see is that it uses lots of POSIX/libc/kernel (Linux, FreeBSD, etc.) system headers, which are not yet available as .bi and are rather hard to auto-translate and maintain in my experience.
Terminal is quite a lot more though, but still counted in hundreds of lines rather than thousands. It is true though that headers (and, more importantly separating them in general *nix and target dependent bits) is the bulk of the work.
Or the FB rts requires a whole lot more than FPC.
Anyway, if anybody wants to try, I'll assist. Just show me how to get a development system installed, and let's go.
Re: Question about rtlib
That's probably true, chances are it only really needs a few declarations from here and there, not full headers.
Re: Question about rtlib
Since we are talking about it... any chances that the patches made by Monochromator for the DOS version could be added? Adding support for threads and dynamic linking would greatly improve the DOS port, in my opinion
Re: Question about rtlib
I do want to try. I will let you know if I need the assist. I assume that is is mostly going to be time consuming. Thanks for the offer.marcov wrote:Anyway, if anybody wants to try, I'll assist. Just show me how to get a development system installed, and let's go.
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: Question about rtlib
It might be good to use FB to augment the runtime library, even if not completely rewrite it.
A couple of advantages I can think of:
- code would be easier for the FB community to read and change/add to.
- we could provide access to object-orientated code, or even just code in namespaces without having to worry about getting the ABI compatibility right in C.
We could start adding includes in FB that feature classes, or even just support for functions in namespaces, and use FB to provide the implementations for those functions/classes in the rtlib.
A couple of advantages I can think of:
- code would be easier for the FB community to read and change/add to.
- we could provide access to object-orientated code, or even just code in namespaces without having to worry about getting the ABI compatibility right in C.
We could start adding includes in FB that feature classes, or even just support for functions in namespaces, and use FB to provide the implementations for those functions/classes in the rtlib.
Re: Question about rtlib
A thing that I would love to add (and that is written in pure FB) is the sound driver I have written (I'd like to have it to work as the graphic library, that is linked only if the program needs it)
Re: Question about rtlib
That's entirely separate. If it's totally portable, works, and has an agreeable API I don't see why a sound library shouldn't be standard.
Personally I'm not interested in rewriting the rtlib for the sake of it, but I am interested in good system headers.
dkl attempted automatic translation of system headers with fbfrog, but it isn't currently used for any of them.
The question is, do we want to minimise labour and go the automatic approach, with the translated headers resembling the originals, or do we want to manually deduplicate the common parts and force them to conform to the same layout? Looks like everyone is in favour of the latter, which basically requires hand-writing/translating everything. It's largely the current approach, but half-hearted: there are still a bunch of differences between different systems, not much deduplication, and it's a bit of a mess. It would be great if we could factor out common POSIX declarations and automatically translate everything else.
Imortis: I recommend you accept marcov's offer if you're serious about this. He knows about this better than anyone here, and you probably don't know the mess you're getting into.
Personally I'm not interested in rewriting the rtlib for the sake of it, but I am interested in good system headers.
dkl attempted automatic translation of system headers with fbfrog, but it isn't currently used for any of them.
The question is, do we want to minimise labour and go the automatic approach, with the translated headers resembling the originals, or do we want to manually deduplicate the common parts and force them to conform to the same layout? Looks like everyone is in favour of the latter, which basically requires hand-writing/translating everything. It's largely the current approach, but half-hearted: there are still a bunch of differences between different systems, not much deduplication, and it's a bit of a mess. It would be great if we could factor out common POSIX declarations and automatically translate everything else.
Imortis: I recommend you accept marcov's offer if you're serious about this. He knows about this better than anyone here, and you probably don't know the mess you're getting into.
Re: Question about rtlib
I have no doubt I will need help at some point. That is why I told him I would ask when I needed it.TeeEmCee wrote:Imortis: I recommend you accept marcov's offer if you're serious about this. He knows about this better than anyone here, and you probably don't know the mess you're getting into.
Re: Question about rtlib
Every system is different, and truely, I only know one RTS and have little FB experience. FB comes with its own sets of constraints.TeeEmCee wrote: Imortis: I recommend you accept marcov's offer if you're serious about this. He knows about this better than anyone here, and you probably don't know the mess you're getting into.
Anyway the best thing would be to first try to reduce the non FB part of the RTS as much as possible. It would make dual maintenance easier and reduce the size of the FB->C interface, making dual maintenance easier.