Re: Intermediate forms (again?): worthwhile?

On 1/19/2011 3:57 AM, Steven Shaw wrote:
> I'd like to second cr88192. i.e. either write a simple interpreter - probably
> an AST evaluator since you're not concerned about performance - or compile to
> C. Another option is to compile to another HLL. C is kinda high-level but
> other choices might be JavaScript (works in browsers and nodejs etc), Java or
> C#. If you stay high-level enough, you might be able to compile to something
> C-ish and only have small differences to your generator to get Cish->JS,
> Cish->Java, Cish->C# etc.


Funny, I didn't remember mentioning compiling to C (or another HLL) in
this thread, but yeah, if ones' goal is to simply "write a static
compiler for some language X", then compiling to C is a fairly
workable strategy, since one can leverage a lot of the work the people
writing the C compiler have already done.






> If you want to be close to the metal, as John said, there's LLVM. The new
> front-runner.


well, it is popular at least, and has a relatively large development
community.




personally I have my doubts about LLVM, mostly:
it is a not exactly small piece of code;
it is written in C++ and doesn't provide a plain-C API (and is written
in what appears to me to be "traditional Java-style OOP", ...), which
may have some additional costs in some cases;
it may well be somewhat overkill;
having to get code into SSA form is not exactly an easy task.


also, admittedly, it doesn't sit well with my design sensibilities. I am
personally more of a fan of modularized black-box components, whereas
traditional OOP practice tends to run counter to this.


decided to leave out some stuff regarding the need of separating
interface from implementation, and the ideal that a person need only
retain just those parts they need and no more, ...




often, a person may just need a simple interpreter, or may have goals
that are not nicely aligned with what LLVM does, in which case using it
is likely be a lot more work than not using it.


even with writing a native code-generator, one may not need so much.
a naive code-generator can typically deliver reasonably good
performance, meaning that many more advanced optimization techniques may
well be more of an intellectual trap than a benefit, and it may not
matter if one supports a variety of CPU architectures.




granted, it is not like LLVM can't be used or anything, but I also don't
believe it to be the "one true codegen" or "solution to all VM
implementation woes" as some seem to assert it to be.


I simply assert here my personal freedom to choose not to use it.






> Another option at some point may be HLVM - a abstraction layer on LLVM as I
> understand it. It's currently in early stages and it's primary author seemed
> to have dropped it until some recent activity.


HLVM could work, although I haven't really looked at it much personally
and so can't really offer any informed comments.




.NET is also possible, but it also has its share of issues, as does the
JVM as well.


ultimately, there may be no "ideal" solution, mostly one can use
whatever solution best matches ones' requirements in a particular
situation, ...

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