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: | stephens@mcs.com (Kurt Stephens) |
Keywords: | design, interpreter |
Organization: | Swiss Bank Corporation CM&T Division |
References: | <3pf727$qn2@goanna.cs.rmit.edu.au> |
Date: | Sat, 3 Jun 1995 10:53:55 GMT |
Status: | RO |
Richard A. O'Keefe writes
>
> This is exactly what Sun are doing with Java. They compile to a portable
> stack machine bytecode format, but for real performance they have a back end
> that converts that to native code. It isn't terribly hard to write a back
> end that can do a *lot* better than even a threaded interpreter, even if it
> is not quite what a highly optimising native-through-and-through compiler
> might achieve.
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. This "bytecode" is supported in hardware by 90% of
the world's computers. ;^)
(Actually I think the x86 is a tired, old instruction set; a poor register
set, etc. but it is the most widely used and is not going away, sigh...)
I would like to see GCC packaged as a linkable library (or a server) so we
can call a function (imagine some thing like "void* GCC_compile(RTL
expression)") with a RTL tree and have it return a function pointer!
Has any one designed an embeddable, portable, retargetable "compiler"
library?
All the best,
Kurt Stephens
stephens@il.us.swissbank.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.