Re: machine independent executables

bct <bct@its63b.ed.ac.uk>
19 Aug 1987 10:24:54-GMT

          From comp.compilers

Related articles
machine independent executables osu-eddie!manson@tut.cis.ohio-state.edu (Robert Manson) (1987-08-16)
Re: machine independent executables bct@its63b.ed.ac.uk (bct) (1987-08-19)
Re: machine independent executables faccs!dbt (1987-08-21)
| List of all articles for this month |

Date: 19 Aug 1987 10:24:54-GMT
From: bct <bct@its63b.ed.ac.uk>
Newsgroups: comp.compilers
In-Reply-To: <660@ima.ISC.COM>
Organization: Dept. of Computer Science, Edinburgh University, U.K.

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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.