OSDev.org

The good thing about FORTH was that you could bring up a new chip quickly - because most of FORTH was written in FORTH. You merely had to code a few key functions in assembler and then compile it in stages. (All per recollection of long ago). The first stage depended on the newly coded assembler functions. The second stage depended on these plus those from the first stage. etc. and so you bootstrapped a system where there was none - using cross assemblers as I recall.

The relevance?

I was wondering whether there is somewhere a heirarchaical chart that shows which members of the C library depend on which members. My idea was that maybe one could quickly (propgramming time) bring up an not necessarily optimnal c library by writing a few functions in assy and the rest depending on those already done - ala FORTH.

This is no doubt an old idea but I am new here so it's new to me.

Suggestions?

Does anyone know of such a heirarchical chart? If there is one it might save me a lot of time in bringing up my system. Or is there source to a C library written as much as possible in C? Maybe I'm answering my own question. I imagine that if I look at Linux or freeBsd I'll find the source to their C libraries - but they will have system calls. Confused. Has someone thought this through? Willing to share your insight?

Both GNU libc (linux and others) and the *BSD libcs are almost entirely in C. I'm not sure how well the BSD libcs are isolated from host-specific code, but I know FreeBSD's was the basis of both Android's Bionic libc and MacOS X's libc. As for glibc, the manual is a good place to start.

Try newlib

What you need in platform-depending code for a standard C library is:

• a function that terminates the process (_Exit())
• a function that allocates memory (malloc())
• a function that deallocates memory (free())
• a function that opens a file (fopen())
• a function that closes a file (fclose())
• a function that seeks in a file (fseek())
• a function that reads from file (fgetc())
• a function that writes to file (fputc())
• a function that removes a file (remove())
• a function that renames a file (rename())
• a function that gives the current system time (time())

Plus a number of defines and constants, like width of integers etc.

I found it helpful to implement those "glue" functions seperate of the standard functions named above, as sometimes you will want to use their functionality out of context of the standard function. Point in case is realloc(), which cannot be implemented in terms of fopen() and fclose() alone.

Hi,
Just posting some extra info, one of the earliest system programming language ( yes !! it was in use even before C came to the existence) BLISS does not define an IO library for itself.

--Thomas

Gentlemen
Thank you so much.
What a fantastic resource.
And a nice bunch of guys.

****