Years ago when C was young and implementations were not readily available people compilers for subsets of C and called then small C compilers.
Currently one of the greatest challenges in LinuxBIOS is to write ram initialization code. On x86 this is all done in 8 general purpose registers. And it takes about a 1000 lines of assembly per memory controller, to do a good job and handle all of the auto-configuration cases. Debugging the assembly is bad as frequently adding the debug code breaks the code we are trying to debug. Additionally there is no code reuse between the two binaries that make up LinuxBIOS as one is in C and the other in assembly.
By this point I have enough practice I am good at writing the assembly code, that I think it hardly matters. But I have seen several proficient coders just grind to a halt when confronted with miles of assembly.
So what I propose is to write a small C compiler for LinuxBIOS. Various reports from ages past put it at about a man-month of effort to get the first version going. And it may be better than that as there are a couple of places I can copy code from. tcc, lcc, gcc, and other small c projects.
Up until this point all C compilers have had an assumption that you can have a stack. And most simple C compilers have kept none of the data structures needed to do inline and similar optimizations that are necessary when you don't have ram.
So I think it is easiest to build up something very simple from scratch. That is the route I am going to try. No promises, but I should start a trial implementation soon.
Ron. I am going to need to do a branch soon as I do the Hammer port and integrate a small C compiler. And I want to make some clean fixes and remove some of the backwards compatibility cruft, and the linuxbios 1.0 code base is an inappropriate place to target. It should be possible to roll in most of the improvements into the 1.0 codebase, but that will just increase the clutter of the codebase.
Eric