Re: Mixing languages

ok@cs.rmit.edu.au (Richard A. O'Keefe)
Sat, 24 Jun 1995 12:31:21 GMT

          From comp.compilers

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)
| List of all articles for this month |

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.
--


Post a followup to this message

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