Ram initialization and small c.

[Eric W. Biederman]

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On 19 Feb 2003, Jeremy Jackson wrote:
> 
> > On Thu, 2003-02-13 at 14:11, Steve M. Gehlbach wrote:
> > 
> > > Will you be able to use the gnu pre-processor unchanged? or adapt it?  The
> > > macro expansion seems pretty important.
> > 
> > FYI, I was reading about newer GCC (3.2?) that have merged the
> > preprocessor into the main parser.
> 
> I have been on the hunt for small c-like compilers. I have yet to find one 
> that runs in the registers only, i.e. has an addressable memory of 16 
> words. 
> 
> My concern about a full-blown c compiler is this: we are going to move
> from debugging 1000 or so lines of assembly to debugging the compiler, and
> shipping a full compiler with linuxbios, just to eliminate this 1000 or so
> lines of assembly.

To shipping a 1000 or so lines of C.   And it is not a full compiler
for all of C just an appropriate subset.  And the output will 
be assembler.

> It seems hard to justify. Since we will be the probable
> only users of this compiler the support burden will fall on us. There are
> not that many people out there needing a compiler that does this "your
> memory is only your register set" capability.

Nope.

> Is there another way? Could we, for example, build a tool that would take
> a description of the actions for turning on memory and generate the code?  
> This would be a specialized "little language". I'm looking for those too
> -- sort of a "meta assembler".

Personally I think it is harder to write a compiler for a declarative
language instead of an imperative language like C.  

> I once wrote an OS using a set of "algol-like" assembler macros. It wasn't 
> perfect but the job of writing the OS was considerably reduced. Should we 
> do this? 

That is essentially what I am suggesting. 
 
> I think we would all like something better than assembly for the hard 
> memory turn-on step, I am just not sure it is a C compiler.

Personally I don't think it will be that bad.  Non optimizing
compilers are straight forward and pretty easy to get right.
The basic trick is not to let the task be overwhelming.

The largest benefit comes from supporting a subset of C, as
that allows code sharing.  I currently have a month in my schedule
to investigate that.  If it looks to hard I will back off but I intend
to give it a good effort.

To my mind this problem is a lot like supporting printf.  A full
printf is scary and huge.  And small subset of printf like we have
now is not to bad and can easily maintained.  And it can be easily
extended to add missing printf features if needed.

In school I majored in languages and I wrote a C interpreter in
a semester, and if I had another week or two it would have been a
compiler as well.  The nastiest most distracting part of a compiler
is the parser, and that we can borrow from elsewhere.  My intention
is to use a recursive descent parser, so the compiler can be easily
tweaked.

And I guess I do not see the maintenance being a major issue.  Small
simple focus programs that don't handle the general case tend
to be easier to write, and maintain.  

Eric