Newsgroups: comp.lang.scheme,comp.compilers
Path: cantaloupe.srv.cs.cmu.edu!europa.chnt.gtegsc.com!news.sprintlink.net!gatech!news.mathworks.com!news.kei.com!world!iecc!compilers-sender
From: ok@cs.rmit.edu.au (Richard A. O'Keefe)
Subject: Re: Mixing languages
Message-ID: <95-06-063@comp.compilers>
Keywords: design, interpreter
Sender: compilers-sender@chico.iecc.com
Organization: Comp Sci, RMIT, Melbourne, Australia
References: <3pf727$qn2@goanna.cs.rmit.edu.au> <95-06-013@comp.compilers>
Date: Sat, 24 Jun 1995 12:31:21 GMT
Approved: compilers@chico.iecc.com
Lines: 32
Xref: glinda.oz.cs.cmu.edu comp.lang.scheme:12949 comp.compilers:8974

I cited Java, with its portable VM.

stephens@mcs.com (Kurt Stephens) writes:

>Why reinvent the wheel with another VM/BYTECODE system?  Use a subset of
>the Intel x86 instruction set and write *ONE* portable emulator for
>non-Intel machines.

For a very simple reason:  there is no subect of the *86 instruction set
that could do the job.  There are at least three goals that a VM for Java
should satisfy:

(1) it should be capable of expressing Java constructs WITHOUT IMPOSING
    TOO MANY IMPLEMENTATION STRATEGIES (e.g. without saying anything about
    the structure of objects in memory)

(2) it should NOT be capable of expressing things that Java doesn't allow.
    In particular, address arithmetic is O-U-T.

(3) it should permit usable direct implementations (e.g. interpreters for
    the abstract machine rather) as well as indirect implementations (e.g.
    translators to native code).

The 80*86 instruction sets are at the wrong semantic level to meet these
goals.  You would need rather more 80*86 instructions to get any desired
effect, and they would reveal/constrain too many implementation details.

--
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
-- 
Send compilers articles to compilers@iecc.com,
meta-mail to compilers-request@iecc.com.
