Re: Backend Question

On 7 Oct 2005 21:45:09 -0400, Suman Karumuri <mansuk@gmail.com> wrote:


>I am planning to implement a *prototype* of a new dynamically typed OO
>language inspired by python and smalltalk


>I am looking at a back end/VM which has the following features.
>- Good documentation
>- Easy to learn
>- Preferably open source and cross platform
>- Should be high level and should do many things out of the box.
>- Code generation should be easy from python
>- Should provide advanced features like GC etc..
>- Speed and efficiency are not the important in the prototype. Even 10
>times slower VM is ok.
  :
>-if i have to implement erlang style processes in future, how much
>does the choice of VM hinder/help the implementation.How can your own
>interpreter help here?
  :
>-Can someone throw light on why we should be writing our own
>interpreter for a new language while discarding the existing ones.


You've already articulated some reasons to develop it yourself: 1)
it's an academic prototype, 2) you desire for it to be "high level",
and 3) you desire an atypical concurrent process model.


To my thinking, the most important reason is #2 - "high level". I
interpret that to mean you want the VM to be closely matched to the
run time needs of your language. Existing VMs were not designed with
your language in mind - at best they won't help you and at worst they
may hinder. Designing the VM concurrently with the compiler allows
you to match implementations and to move the boundary between compile
time and run time as necessary to make your life easier. It allows
features to be implemented in the compiler, in the VM, or to be
distributed between them in any convenient way.


Academic quality VMs are not difficult and you can leverage features
of the implementation language to make the job easier. For example,
GC in the implementation language can provide GC for the VM
eliminating the need to roll your own. Same with threads - I've never
used Erlang, but I know its processes are based on message passing
coroutines ala Hoare's CSP. This model is easy to build on top of any
kind of existing threads. Rolling your own threads ranges from really
easy to really hard depending on the implementation language.


It's obvious from your post that you don't *want* to deal with machine
level details, so don't use (or design) a VM that mirrors the machine.
Instead design a VM that best matches the actual needs of your new
language and implement it using a language that provides as much
built-in support as possible for the VM requirements. Let the
implementation language worry about the low level details.


George

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