Xref: utzoo comp.arch:6465 comp.lang.c:13101 comp.lang.misc:1955 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!nrl-cmf!cmcl2!rutgers!cbmvax!snark!eric From: eric@snark.UUCP (Eric S. Raymond) Newsgroups: comp.arch,comp.lang.c,comp.lang.misc Subject: Re: Machine-independent intermediate languages Message-ID: Date: 5 Oct 88 18:02:45 GMT References: <853@goofy.megatest.uucp> Sender: eric@snark.UUCP (Eric S. Raymond) Organization: Somewhere in Hyperspace Lines: 115 Aha! Finally, an apologia for the MIIL comcept that makes sense... In article <853@goofy.megatest.uucp>, djones@megatest.UUCP (Dave Jones) writes: > From article , 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@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@snark.UUCP Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718