I haven't been working on the language for quite some time now. I recently started again. Puzzling thought: I now added two extra internal languages to the compiler. A minimalist untyped lambda calculus core language, and a code language, which should abstractly represent the C subset I am compiling to.
Why? These are two extra levels of indirection, which if I look hard at them, are slightly more direct (no meta-information to handle), but I think I can get away with restricting myself to the original abstract syntax, meanwhile ascribing a slightly different semantics while converting.
Ever considered LLVM or C--? That would prevent you from having to write your own machine code generator, and make things such as the proper treatment of tail calls much easier to perform...
ReplyDeleteHi Leon, guess I've seen you on LtU, I didn't see you posted here, it doesn't show old remarks.
ReplyDeleteDifferent treatment of tail calls is unnecessary given the translation scheme I use, a simple LC to combinators to C translation. I just push thunks/stack frames into the heap, there is no need to treat a tail call any different than any other recursive call.
I am not going for optimum speed, I just need code which is maintainable and readable for _years_, before I obfuscate it for optimizations.
I aim at developing a commercial product, ok, wishful thinking here, which means LLVM and C-- are out. C is widely understood, LLVM and C-- are back-ends I don't want to deal with. C has been there for -what- forty years or so, and I don't see it going away for another forty years. LLVM and C-- are nice, but, hey, C-- looked nearly dead last time I looked. LLVM is going strong, but will not be around in another few years.
Anyway, as it stands, I produce very basic C code from a rather abstract assembly, which could be compiled rather trivially to other targets, but I am not going to make the effort.