johnl@ima.ISC.COM (John R. Levine) (08/19/87)
[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] -- 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 -- John R. Levine, Cambridge MA, +1 617 492 3869 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something The Iran-Contra affair: None of this would have happened if Ronald Reagan were still alive.