Question

I’ve got a few languages I’ve been building as interpreters. When I’m ready to take ‘that next step’, what options are best for non-native compiled formats… what are the pros and cons of each?

I’ve been looking at compiling to CLR or LLVM, and contemplated C-midcompile a few times, but I’m not completely certain.

A few features I’m hoping to be able to port are as follows:

1. REPL – One of the languages I’m building supports block-level evaluation during runtime.
2. Robust Macros – One of the languages I’m building requires the ability to filter through code seperately before tokenizing, and in the midstep between tokenizing and parsing.

Ok, not really ‘a few’, just two. I like to think I can port any other features my languages support to ‘anything’.

What are my best options, and their pros/cons?

Answer 1

pro/cons:

• CLR:

  • pro: CLR environment readily available; a lot of stuff to bind to
  • con: bound to CLR (;-); targetting some systems will be hard or impossible (embedded, mainframes, etc. CLR impl. might be less mature on non MS systems)

• LLVM:

  • pro: independent from MS.
  • con: targetting some systems might involve porting LLVM (?); interfacing to DOT-net, Java etc. might be troublesome (possibly needs FFI)

• C as target language:

  • pro: almost all targets possible; easy code generation
  • con: you will have to implement some VM stuff as runtime library (GC, dynload, dyn compilation etc.); some things are hard to do in C (continuations, backtracking, stack tracing, exceptions); some things are hard to do efficiently and portable in C (GC, dynamic types, stack layout dependence).

• Java ByteCode as target:

  • pro: probably the biggest set of possible target platforms (even mobil phones and embedded stuff); a lot of existing tools around; easy interfacing to existing libraries
  • con: some things are hard to implement or hard to implement efficiently (dynamic types, continuations, backtracking)

From all the above, I think targeting Java ByteCode would probably be best for you.

EDIT: actually an answer to a comment, but 300chars are not enough.

JByteCode iffy – I agree (being a Smalltalker, JBytecode is too limiting for me).

VM-wise, I think there is a relatively wide range of performance you can get as JVM, starting at pure slow bytecode interpreters up to high end sophisticated JITting VMs (IBM). I guess, CLR VM’s will catch up, as MS is stealing and integrating all innovation anyway sooner or later, and the techniques to speedup dynamic translation are published (read the Self papers, for example). LLVM will probably progress a bit slower, but who knows. With C, you will benefit from better compilers for free, but things like dynamic retranslation etc. are hard to implement with C as target. My own system uses a mixture of precompiled and dynamically compiled code (having all: a slow bytecode interpreter, JITter and precompiled static C-code in one memory space).