Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!necntc!ima!johnl From: bct@its63b.ed.ac.uk (bct) Newsgroups: comp.compilers Subject: Re: machine independent executables Message-ID: <678@ima.ISC.COM> Date: Wed, 19-Aug-87 06:24:54 EDT Article-I.D.: ima.678 Posted: Wed Aug 19 06:24:54 1987 Date-Received: Sat, 22-Aug-87 11:13:18 EDT Sender: johnl@ima.ISC.COM Reply-To: bct Organization: Dept. of Computer Science, Edinburgh University, U.K. Lines: 52 Approved: compilers@ima.UUCP In-Reply-To: <660@ima.ISC.COM> In article <660@ima.ISC.COM> you write: >I think the pseudo-code would be a good idea. However, why not make a >compiler for the pseudo-code? Many machines use a similar architecture; I'd >think (in my naivete) it'd be easy to design a code to take advantage of >that fact. The code (assuming it were similar enough to the machine code >of the machine it was running on) could be compiled each time it was loaded >into memory, making it convenient to use (not having two versions laying >around). See the old paper "The problem of Programming Communications with changing Machines" by Strong, Wegstein, Tritter, Olsztyn, Mock & Steel. CACM Vol. 1, No. 8, page 12, 1958. [The UNCOL paper] also, "Janus: A Universal Intermediate Language", S.A. Coleman Phd Thesis, University of Colorado, 1974. [Available from NTIS #PB 232 923] and, "The Portable Compiling Systems of MUSS" by Barringer, Capon & Phillips. Software Practice and Experience, Vol 9, pp 645-655, 1979. I was involved with the production of compilers related to the MUSS system. We generated ".o" files which were in the intermediate code form and "ld" produced executables from them. We had a Pascal, C, Basic, and [GSA validated] Fortran 77 compilers all generating the same intermediate form in the ".o" files. The linker "compiled" the intermediate code into the appropriate machine code. Code generators existed for MC680x0, PDP11, VAX11 plus many research and proprietary machines. Further we had optimisers that worked at the intermediate language level and optimised from ".o" to ".o", as well as optimisation passes during final code generation. It was not advertised to the users that the compilers were not generating native code, and the linker was doing a little more than linking. Not many of them noticed. Many complimented the compiler group at the speed of the compilation. The "linking" was just as slow as other systems linkers; this helped the ruse. You can [still] buy a system containing these compiler, but I won't say which label they bear. Brian. -- Brian Tompsett. Department of Computer Science, University of Edinburgh, JCMB, The King's Buildings, Mayfield Road, EDINBURGH, EH9 3JZ, Scotland, U.K. Telephone: +44 31 667 1081 x3332. JANET: bct@uk.ac.ed.ecsvax ARPA: bct%ecsvax.ed.ac.uk@cs.ucl.ac.uk USENET: bct@ecsvax.ed.ac.uk UUCP: ...!seismo!mcvax!ukc!ecsvax.ed.ac.uk!bct BITNET: psuvax1!ecsvax.ed.ac.uk!bct or bct%ecsvax.ed.ac.uk@earn.rl.ac.uk -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request