"Ronald G. Minnich" rminnich@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