machine independent executables [digest]

[Here are a bunch of messages on the topic grouped together, because
I think the issues involved are more system design than compiler oriented.
-John]


------------------------------


From: cullvax!drw@EDDIE.MIT.EDU (Dale Worley)
Newsgroups: comp.compilers
Subject: machine independent executables
Date: 18 Aug 87 14:00:47 GMT
Organization: Cullinet Software, Westwood, MA, USA


osu-eddie!manson@tut.cis.ohio-state.edu (Robert Manson) writes:
> 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). [...]
> I think [...] 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).


It seems to me that in order to get reasonable speed at load time, you
have to make sure that the machine-specific translation process is
very fast. This requires that either the intermediate code is very
close to the machine code, or that the intermediate code only
represents operations that can be performed straightforwardly on most
architectures. I suspect that this constrains the intermediate code
to look like machine code for a stack-oriented architecture.
Certainly, it couldn't try to be clever about register usage or
instruction choice (above the level of simple peephole optimizations).
I'd guess that this can gain you a factor of 2 to 3 over interpreting
bytecode, but not much more.


Dale
--
Dale Worley Cullinet Software ARPA: cullvax!drw@eddie.mit.edu
UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw


------------------------------


Date: Tue, 18 Aug 87 08:49:14 pdt
From: harvard!ames!felix!preston (Preston Bannister)
Subject: Re: machine independent executables
Organization: FileNet Corp., Costa Mesa, CA


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


I went directly from working at Western Digital on the MicroEngine to
working at a Burroughs Large Systems plant. Western Digital made a
microcomputer called the MicroEngine based on a processor called the
P-machine. The P-machine executed p-code directly. The processor was
originally designed (circa. 1976) to sell to Digital as a LSI-11
processor with a different set of microcode.


As an interesting sidelight, the original Byte Sieve benchmark article
listed the MicroEngine. In terms of the run time of the benchmark, the
p-machine was several times slower than even Z-80's. the interesting
part was the time to compile and link the program. All the Z-80
compilers took on the order of a minute or more. On the MicroEngine
the benchmark program could be compiled in a few seconds!


--
Preston L. Bannister
USENET : ucbvax!trwrb!felix!preston
BIX : plb
CompuServe : 71350,3505
GEnie : p.bannister


------------------------------


From: harvard!seismo!ihnp4!killer!molly (Molly Fredericks)
Newsgroups: comp.compilers
Subject: Re: machine independent executables
Summary: Have starting working on the machine
Date: 19 Aug 87 04:28:24 GMT
References: <660@ima.ISC.COM>
Organization: The Unix(tm) Connection, Dallas, Texas


In article <660@ima.ISC.COM>, osu-eddie!manson@tut.cis.ohio-state.edu (Robert Manson) writes:
> 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. [ ... ]


Yes, I picked up on that discussion just as I added this group to my reading
list. I have already received ten or so letters from people interested in
doing a project like this. Here is where the `project' is so far:


Need to design the machine, _first_.
- probably a one and a half or two address machine, smelling
alot like a PDP/11 or an M68000.
- probably eight or sixteen registers, mostly general purpose
- definitely not a `RISC' virtual machine, that would definitely
bog this puppy down just doing the lookups in a switch table
(or least ways this CISC brain thinks that way.


Need an emulator.
- should be written in simple C. I want to rewrite it in the
`native' language of the machine ...
- needs to provide an interface to the operating system, plus
some debugging facilities (thanks to David Goodenough for
reminding me about operating systems :-)


Need an assembler.
- maybe the portable assembler could be munged on to get it to
work on this guy.


Need a compiler.
- C or otherwise.
- I have a language I want to put on this thing, but the compiler
is written in C, so no big deal ...


Need an operating system.
- of course, what else do you do with a virtual machine?


Anything else you can think of, including designing the silicon
to build a real one with.


Sounds like fun to me, so when do we start?


Molly
--
              Molly Fredericks UUCP: { any place real }!ihnp4!killer!molly


------------------------------


From: mpl@sfsup.UUCP (M.P.Lindner)
Newsgroups: comp.compilers
Subject: Re: machine independent executables
Summary: some Smalltalk compiler solves it this way
Message-ID: <1872@sfsup.UUCP>
Date: 18 Aug 87 18:22:32 GMT
References: <660@ima.ISC.COM>
Organization: AT&T-IS, Summit N.J. USA
Lines: 20


In article <660@ima.ISC.COM>, johnl@ima.UUCP writes:
> There has been a discussion on comp.unix.wizards about multiple machine


I remember reading about some smalltalk interpreter/compiler that did the
following:


The smalltalk was compiled to its internal form. The interpreter would
read this *as each function was invoked the first time*, generate code
for that function, and execute it. The next time the function was invoked
the code could just be executed, since it was now compiled, native machine
code. Of course, there were many problems, due to the way smalltalk works,
that could make the compiled version useless (in which case it would
detect this and recompile with the new parameters), but for C this should
be *very* easy to implement.


I'm sorry I didn't pay more attention. I don't have any refernces, but it
sounds like a neat idea, and efficient, too!


Mike Lindner
ihnp4!attunix!mpl


[Compilation on demand is another reasonable idea that has independently
arisen many times. I ran into it in the APL interpreter for the HP 3000,
which, the first time it encoutered an expression would compile tight code
that assumed the expression's inputs would always have the same rank and
size, then if a subsequent execution had inputs which were shaped differently,
it'd compile less tight code that made fewer assumptions about the shape of
the input, and then if the inputs still kept changing shape, it'd just
recompile it each time it needed to. Worked OK, though the 3000's
architecture caused some painful limitations. -John]
--

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