Re: Intermediate forms (again?): worthwhile?

On 1/13/2011 10:53 PM, Tony wrote:
> As a language designer/developer, I feel like I'm in between the
> proverbial rock and hard place. I'm A-OK with doing the "front end" of
> the compiler, but the "back end" is "kinda scary" for me. To "spill", my
> path is, currently, compiling to assembly language (am I naive?). I mean,
> it's "simple", right? What can go wrong, having full control (ignore
> multi-platform compatibility, for it is NOT in my requirement now)?


<snip>




> [If you don't plan to do much optimization, you don't need a complex
> internal form. For a really simple compiler, you can often just make a
> tree for each statement, then walk the tree to generate the code and
> throw the tree away. Or if you're clever enough, emit the code directly
> from the parser. -John]


yes, true...


it is better to start off simple, and then try more complex options when
one feels more comfortable with them.




other possible suggestions I think:
do an interpreter;
use threaded code.


both of the above options have merits:
an interpreter allows more easily producing code fragments at runtime,
and can be fairly simplistic. interpreters are a good option for
scripting languages.


interpreters come in several common variations:
AST interpreters, where the output of the parser (the AST) is executed
directly (one can walk the tree and directly perform operations);
bytecode interpreters, where the AST is converted into some
bytecode-based format and then the bytecode is executed (such as via a
big "switch()" statement or similar).




threaded code allows blurring the lines between interpretation and
compilation, while still maintaining many of the merits of an
interpreter (namely, most or all of the logic is function-calls, which
call into interpreter logic), but can be a little faster and allows a
few additional possibilities, and need not compromise portability.


threaded code could be produced directly from the AST, or possibly
bytecode can be generated and then translated into threaded code (this
is a strategy being tried for a newer interpreter of mine in development).




now, for static compilers, another common option for simple compilers is
to compile to C. this has the advantage of being portable, but does
require a working C compiler.


a compiler producing ASM is not *that* difficult, and due to more subtle
reasons, modern computers are actually fairly forgiving WRT compiler
output (most of the effort and complexity going into compiler
optimization is trying to "shave off that last few percent", and much
past simple optimizations quickly becomes diminishing returns IMHO, and
one is likely better off if they avoid trying to optimize things in most
cases unless there is a strong reason to do so).


however, even so, producing ASM is still a bit more work than producing
C, as there are many simple things a C compiler will do, which one has
to deal with manually if producing ASM.




and, speaking from personal experience: be careful of underestimation.
underestimating a the difficulty of doing something is very easy to do
here, and may rapidly lead to bad results (complex or unworkable code,
getting stuck on something, ...).


so, it is better to use a bit more caution than would be needed for most
other types of projects.




also, be careful of "good and proper" practices, as often, there be
dragons there (I have partly had to learn this one from experience).
just because some other project has done something a certain way,
doesn't mean one necessarily has to do similar themselves, as not all
projects have necessarily done things in the best possible way (and, as
a rule of thumb: if a design idea seems stupid up-front, it probably is...).


although, the reverse is also often true: "new and innovative" ideas can
also often be bad ideas as well (if one has an idea and wonders "why
doesn't anyone/everyone else do it this way?" research may often reveal
that there is a good reason for this). not everything "new" is
necessarily gold.


so, it is partly a matter of striking a balance.
(and in my experience I have fallen into more than a few traps over the
years).




but, yeah, it all can still be an interesting or rewarding experience...

Return to the comp.compilers page.
Search the comp.compilers archives again.