Machine-independent intermediate languages

[Dave Jones]

>From article <e2uEl#2ORJzO=eric at snark.UUCP>, by eric at snark.UUCP (Eric S. Raymond):

> 
> 	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.

	If you are going to have different compilers for HHL work and
        MIIL work, you might as well have two different languages, so...

        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, 
           provided that a check-sum is correct (or on very dependable 
           systems, providing that a "magic number" is correct). It need
           not spend valuable cpu cycles checking on correctness.

           b. The HIIL compiler should not do any "optimization" which
           could possibly affect program operation in any way.  In
           particular, it should always evaluate expressions in the
           order in which it is told to evaluate them.  That leaves
           many C compilers right out.  It should do no global optimizations.
           (Global optimizations are machine-independent, and should
           be performed on the MIIL form or on an earlier form, before
           the MIIL compiler sees it.)
           
> 
> 	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.

> 	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.

> The whole debate so far has been about 2). I am trying to suggest that the
> critical question is actually 3), that the answer to 3) appears to be 'no',
> and that the notion of MIIL is therefore fundamentally rather pointless,
> because it distracts us from the *important* questions about designing
> portability into HLLs.

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).
   2) C cross compilers do not exist for the machines in question.
   3) Current C compilers for the target machine are too slow to 
      use interactively in a read-compile-load-run loop ("executing data").

Admittedly, the second two reasons are not due to the nature of C itself, 
but rather to the nature of current compilers.  I had rather see
more work go into new MIIL's, and indeed, new HLL's rather than seeing
yet another batch of C compilers.  Nobody is going to do new C compilers
tuned to be used as MIIL compilers.  For marketing reasons, the new
compilers will all do ANSII prototypes and lots of optimization.

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.