Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!bellcore!faline!thumper!ulysses!gamma!sword!arrow!yba From: yba@arrow.bellcore.com (Mark Levine) Newsgroups: comp.arch Subject: Re: Machine-independent intermediate languages Message-ID: <907@sword.bellcore.com> Date: 5 Oct 88 16:58:06 GMT References: <898@sword.bellcore.com> Sender: news@sword.bellcore.com Reply-To: yba@sabre.bellcore.com (Mark Levine) Organization: Bellcore, Red Bank, NJ Lines: 70 In article eric@snark.UUCP (Eric S. Raymond) writes: >In article <898@sword.bellcore.com>, yba@arrow.UUCP (Mark Levine) writes: > > 2) Are the portability goals for which MIILs are designed achievable > at all, given the diversity of today's architectures? > > 3) If the answer to 2 is 'yes', *can those goals be achieved with > lower complexity and cost than an HLL compiler?* > >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. [Sorry I seemed to ignore this -- we lost our active file a few days ago and I missed your response.] I believe we are in agreement here. >> I beleive in such a thing as a MOL, a machine oriented language, and >> in a high level machine oriented language which is portable. It is >> possible to do MUCH better than C. > >Fine. I don't so believe (I've seen too many bizarre architectures) but I have >an open mind. Show me! I can point at MARY again. (Or maybe LIS). We probably need to define what "better" means here -- I mean to have the most expressive power available to the program writer as well as to generate fast and tight code. I do not mean to limit yourself to expressing semantics which can be efficiently compiled on all architectures, which may indeed be what MIIL language proponents are looking for. If my highly optimized vax program runs half as fast on your sun, I still think it is portable; if you can change an implentation prelude or a generic sort package from my vax library to your sun library and it runs just as fast, I think we are winning. A machine oriented language, or high level assembler if you prefer, is not predicated on a portable intermediate representation. I think all it needs guarantee is you _can_ get at the machine language ops if you want to, and that you can supply (presumably non-optimal) replacement semantics for other architectures. In other words, you write a code generator and some implementation specific code for each target. This is the same as doing an HLL, yes? (If you _have_ optimal replacement semantics, you would of course use them.) An asm escape does _not_ fit this need. The big difference is being able to add high level constructs (language expansions if not language extensions) with user defined semantics, in the source language, which can go all the way to the machine language. C is not all that portable, although it is popular to think of it as both machine close and easily portable, because the source code writer must explicitly handle his portability constructs (#ifdef the bytes go _this_ way, except #ifdef I am on an IBM RT unless #ifdef this is a 16-bit machine...). It lacks most of the features I really want for large systems and toolkits (give me operator overloads, full typing, generic instantiation, a function value language that goes left to right, implicit operator definitions and explicit modules with separate compilation -- not to exclude dynamic linking). Without a position to protect (at RPI they used to say: "An open mind has but one disadvantage: it collects dirt") I will go as far as to say if you took the restrictions (built in for verifiers we will never build) out of ADA, you could do better in ADA than in C. I am also willing to learn; show me why not? Let me go further in agreeing with you and say that getting the kind of portability I described above ("winning") _must_ be achieved in the HLL. By the time you get to an IL, you have lost the most important information of all -- what the writer was trying to do! The ability to optimize the operation make-symbol-table" or "cubic-spline" is much more useful than the ability to optimize move-indirect-through-autoincrement-register. Eleazor bar Shimon, once and future Carolingian yba@sabre.bellcore.com