Related articles |
---|
Re: Mixing languages stephens@mcs.com (1995-06-03) |
Re: Mixing languages pardo@cs.washington.edu (1995-06-05) |
Re: Mixing languages ok@cs.rmit.edu.au (1995-06-24) |
Re: Mixing languages gbaker@rp.CSIRO.AU (1995-06-27) |
Re: Mixing languages jdean@pysht.cs.washington.edu (1995-06-28) |
Newsgroups: | comp.lang.scheme,comp.compilers |
From: | ok@cs.rmit.edu.au (Richard A. O'Keefe) |
Keywords: | design, interpreter |
Organization: | Comp Sci, RMIT, Melbourne, Australia |
References: | <3pf727$qn2@goanna.cs.rmit.edu.au> 95-06-013 |
Date: | Sat, 24 Jun 1995 12:31:21 GMT |
Status: | RO |
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.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.