Wow. Cool. I had dreams of this, never thought anyone would attempt. Imortis, kudos. Thank-you for putting your self out there, asking questions, willing to learn. Awesome.
Allow me to offer a few comments:
MEMCPY: an optimization for sure. See
memcpy.c. Implemented trivially as a for(), char * copy loop. Hand-rolled ASM existed in DJGPP since 1995.
Dependency on C runtime: to completely replace common C runtime on all platforms will be a monumental task. Even if major parts of libfb rewritten in FB, plan for a mix of C and FB. At some point you have to interface with the execution environment. Leverage the work of others and target what is typically available on most platforms - a working standard common C runtime - initially at the very least. Especially file I/O, pipes, shell & process execution.
I had a hand in writing serial and printer drivers on dos/win/*nix, something that does not exist in standard C runtimes. Every platform is different. And each had to be written specifically for each platform. Even within windows environment, different code paths for win98, winxp, etc.
FBRT0.bas: to write this as pure FB, then would have to add an __attribute__() type feature in to FB. I was responsible for the C hacks you see in fbrt0.c. Purpose is to initialize C runtime, then FB runtime, in that order. Ultimately __attribute__() controls the linker and where the global ctors/dtors get added. We tried other solutions like custom linker scripts, but ultimately the C hacks were the most portable (within gcc world). But even with C this is non-standard and not completely portable as DJ handles global ctors/dtors in DOS differently than on win/*nix. Quite possible that unknown future targets will be different from anything seen so far.
What will be most challenging is implementing the run-time in FB without using any feature you would normally get from the FB runtime. For example, can't use STRING in the run time, because from the run-time point of view, it doesn't exist yet.
Question: what is the varied use of Extern "C", cdecl, FBCALL? Not saying it is wrong, I just don't understand.