Xref: utzoo comp.arch:6519 comp.lang.c:13215 comp.lang.misc:1969 Path: utzoo!utgpu!attcan!uunet!husc6!bloom-beacon!mit-eddie!rutgers!bellcore!faline!thumper!ulysses!gamma!sword!arrow!yba From: yba@arrow.bellcore.com (Mark Levine) Newsgroups: comp.arch,comp.lang.c,comp.lang.misc Subject: Re: Machine-independent intermediate languages Message-ID: <912@sword.bellcore.com> Date: 10 Oct 88 14:49:16 GMT References: <358@istop.ist.CO.UK> Sender: news@sword.bellcore.com Reply-To: yba@sabre.bellcore.com (Mark Levine) Organization: Bellcore, Red Bank, NJ Lines: 30 In article <358@istop.ist.CO.UK> itcp@ist.CO.UK (News reading a/c for itcp) writes: >I have another interest in MIIL and that is as a Language independent >intermediate code to promote the design and disemination of new programming >languages. Clearly it would be acceptable for the MILL implementation >cost to exceed the cost of a single HLL compiler, so long as it was cheaper >than two HLL compilers. If it were more expensive than that I would seriously >doubt its reliability and maintainability. > Eariler in this discussion I mentioned MARY. After recently talking to the fellow who taught it to me, I should add that he is working on the third generation of the language, and that to make this "new programming language" available, the target for the compiler is C. Given that most new machines these days get C as part of the initial language suite, even though it is not all things to all of us, perhaps (I was wrong and) we already have a _de facto_ MIIL. If the machine model under a particular C compiler is doing the "Wrong" thing (ala the discussion of Burroughs segments), you would have to have assembler escapes or your own code generator to get around it. This still sounds like a cheaper way to get started than porting a virtual machine. Perhaps the better topic is how much it costs to do better than C, rather than whether one can. In the context of the quoted article, I would consider C not to be an HLL. In the same context, let me agree with earlier postings and ask what are the objections to calling C the MIIL in question and saying it is already done and has zero new costs? Certainly an interesting way to distribute reliability and maintainability costs. Perhaps also a good reason to be locked into a "standard" C. Eleazor bar Shimon, once and future Carolingian yba@sabre.bellcore.com