johnl@ima.UUCP (08/17/87)
There has been a discussion on comp.unix.wizards about multiple machine
executables (attempting to solve the portability problem, making it easier
to compile a program to run on several machines). Anyone over here have
an opinion? One suggestion was to use a pseudo-machine code and an
interpreter; however, I think the loss in speed would be a major drawback.
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).
I sincerely believe this is a very good idea. I would be willing to
go so far to write a C compiler for such a "machine" (assuming someone else
were to design the machine) if there were enough interest. Of course, it might
be possible to use an existing compiler (anyone know of any that could be
suitably modified)?
Bob Manson ...{ihnp4,cbosgd}!tut!manson
[This is a topic that has been around for a while. Compiling to a byte code
and interpreting is quite commonly used in, for example, the Pick system.
Machine independent intermediate code, though, is a famous black hole,
particularly when you are trying to deal with machines with different word
sizes, addressing architectures, and byte orderings. The best known example is
Pascal P-Code, which works at the expense of making all machines act sort of
like a CDC 6600, its original host. -John]
--
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-requestbct@its63b.ed.ac.uk (bct) (08/19/87)
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
johnl@ima.UUCP (08/21/87)
In article <660@ima.ISC.COM>, johnl@ima.UUCP writes: > There has been a discussion on comp.unix.wizards about multiple machine > executables ... In MIT AI Memo 379, Guy Steele made the case for Scheme (i.e. essentially the lambda calculus) as an appropriate intermediate code. The argument is that an intermediate code should not try to model the imperative nature of the machines, that that is too low-level. Instead, what Scheme offers is a 'low-level' model of control-flow (if, goto) and environment/renaming (lambda) that is the essential common denominator and yet completely independent of *any* particular machine. In addition, it is relatively easy to write a portable interpreter for Scheme (they already exist, e.g. MIT Scheme is in 'portable' C) and there are good compilers available on a wide variety of machines ('T', from Yale is excellent and is only $200). Compare this to the task of developing yet another compiler and designing the intermediate code just to get a project off the ground. A lot of issues would still remain, but it seems to me a good starting point. I would be interested in discussing this further or elaborating on the advantages of Scheme. [Scheme is as good an intermediate language as any, but the T compiler, like most Lisp compilers, generates code to be added into a running T environment rather than a standalone program to take away. Also, it doesn't help the nitty-gritty issues like alignment and byte order. -John] -- Wage Peace, Patrick Logan (dbt@faccs) uw-beaver!ssc-vax!shuksan!tahoma!bcstec!faccs -- 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