Machine-independent intermediate languages

[Eric S. Raymond]

Aha! Finally, an apologia for the MIIL comcept that makes sense...

In article <853 at goofy.megatest.uucp>, djones at megatest.UUCP (Dave Jones) writes:
> From article <e2uEl#2ORJzO=eric at snark.UUCP>, by me:
> > 	1) What properties distinguish a MIIL from a HLL?
> > 
>         The HLL should be easy for humans to write.
>         The MILL should be in the form most easily generated by compiler
>         frontends, which is to say, it should be Polish form, not 
>         infix.  Probably postfix-Polish is best.

I consider this a detail. Front-ending is *not* the hard part in HLL
compilation; front ends are easy to write, and easy to port. Code generation
is the hard part. Eliminating the front end, by itself, doesn't pare away
enough complexity and cost to justify the MIIL concept.

>         Now, I'll answer a question you did not ask: Namely, how should
>         an MIIL compiler operate differently from an HLL compiler?
> 
>            a.  The HIIL compiler may assume that its input is correct, 

Again, this is a *front end* issue, and front ends are the *easy* part.
Code generators (which are, typically, IL-to-native-code translators) don't
typically error-check their input stream, either!

Here's a gedankenexperiment for you. Let's suppose we *had* a "universal" MIIL;
now, I write a HLL front end in it, and I ship that with uMIIL. Do I have a
universal HLL compiler? Given that assumption, yes I do.

What this demonstrates is that, aside from an essentially fixed *one-time* cost
to write an HLL front-end, the cost and complexity of writing a uHLL is the
*same* as that of writing a uMIIL!

(BTW, please forgive the proliferation of jargon but I am *not* going to wear
out my typing finger on "universal machine-independent intermediate language"
again)

Now, what's wrong with this picture?

Again, *we left out the hard part* -- which is designing the uMIIL/code
generator and then implementing it on the billyuns and billyuns of bizarre
boxes out there.

>            b. The HIIL compiler should not do any "optimization" which
>            could possibly affect program operation in any way.

So how's this different from an HLL with the optimization turned off?

> > 	2) Are the portability goals for which MIILs are designed achievable
> > 	   at all, given the diversity of today's architectures?
> > 
>         I know from experience that a completely general solution is tough.
>         Most of the problems come from screwy pointer-formats. Still, you
>         can come up with something that works for "reasonable" 
>         architectures.

Certainly. It's called 'C'.

No flames about C's problems, please. I know it's not perfect. But the *fact*
is that it is now filling the niche in the computer science ecology that you're
describing -- and you haven't advanced any compelling reasons to abandon its
HLLness in favor a search for a hypothetical uMIIL.

> > 	3) If the answer to 2 is 'yes', *can those goals be achieved with
> > 	   lower complexity and cost than an HLL compiler?*
> > 
>         I think probably so.  Certainly one can design an MIIL which
>         is easier to generate code for (in the front-end) than currently
>         popular HLL's.

Let's assume you can. So what? Front-ending (I guess I have to repeat this
again) is *not the real problem*! As long as you have to write a nontrivial
code generator anyhow (and you will, for any hardware that doesn't closely
match the virtual machine defined by the uMIIL) the complexity and cost of
that back end is going to completely swamp the cost of hauling along and using
an HLL front end.
 
> As a practical matter, I can't agree.  As we speak, I am writing an 
> HLL compiler. I wish I had a good MIIL and some cross-compilers for it.  
> Current implementations of C will not do because, 
> 
>    1) Generating C code is a pain in the butt (c.f. Cfront).

Maybe your translation methods need work. Have you tried treating your
new-HLL parse tree as data and doing rewrites on subtree pattern matches until
you get legal C? That way C gets to do the grotty parts like symbol table and
name space maintenance. Use LISP for this if you can, then compile the LISP.

>    2) C cross compilers do not exist for the machines in question.

Given what I've shown above, why do you consider uMILL 'cross-compilers'
to be significantly easier/more feasible? (and do you see why this is the right
question now?)

>    3) Current C compilers for the target machine are too slow to 
>       use interactively in a read-compile-load-run loop ("executing data").

An implementation detail, as you yourself observed.

> Even if it is possible to define a language which will serve as both
> an HLL and an MIIL, (an "MIHLL"), it sure would be nice to have the MIIL 
> to boot strap it with.  Perhaps the MIIL would turn out to be a 
> subset of the HLL with "checking turned off", I dunno.

Ah. Now *that's*, in my opinion, the right lesson to draw from thinking about
MIILs -- that we need more don't-try-to-second-guess-me switches on our HLL
compilers.
-- 
      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)
      UUCP: ...!{uunet,att,rutgers}!snark!eric = eric at snark.UUCP
      Post: 22 S. Warren Avenue, Malvern, PA 19355      Phone: (215)-296-5718
-- 
      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)
      UUCP: ...!{uunet,att,rutgers}!snark!eric = eric at snark.UUCP
      Post: 22 S. Warren Avenue, Malvern, PA 19355      Phone: (215)-296-5718