1

I'm currently looking at different virtual machines to run a host of different scripted languages (in an embedded manner).

Two VMs that have caught my eye are:

  • LLVM: While I have seen posts that suggest not using LLVM as an VM, it does seem to have a lot going for it. It can do optimization, JIT, has a nice debugger already, etc. While there doesn't seem to be too much documentation on using LLVM in this manner, there is Cling which is capable of running c++11 as an interpreted language (which is pretty impressive), as well as the command-line tool 'lli'.

  • libJIT: Technically this isn't a VM, but provides the necessary tools to create one.

So my questions are:

  1. Does anyone have experience with either of these VMs and can give negative/positive experiences.
  2. I've gone through a lot of the documentation for both LLVM and libJIT, but wanted to check if anyone had any recommendations for other resources (esp. for LLVM).
  3. Are there other VMs out there that I should consider? I've done some fairly extensive searches, so this not a question of what VMs are out there, but rather one of software that people have used and would recommend.

As for actual use of the VM I'm intending to embed the VM within a c++ program to provide a scriptable user environment. I'm already using Lua for some of the stuff, but for various reasons I want to be able to support other languages as well.

Finally, I've looked at Parrot, but I am a little hesitant to use it from some of the things I've read about it (maybe someone can convince me otherwise?).

update

I came across http://vmkit.llvm.org, which looks like it uses LLVM to create a full-fledged VM.

Seki
  • 11,135
  • 7
  • 46
  • 70
Abe Schneider
  • 977
  • 1
  • 11
  • 23
  • 1
    LLVM isn't a VM either. Like libJIT, it only provides tools to create VMs (and, unlike libJIT, also tools for ahead of time compilers). Don't confuse Cling with LLVM, and note that Cling uses Clang (a C, C++ and ObjC compiler *built on* LLVM). What are you actually looking for? A VM that 'supports multiple languages'? And what does that mean exactly? (cf. [XY problem](http://meta.stackexchange.com/q/66377)) –  Feb 20 '13 at 16:23
  • What about JVM? You could have all these languages: http://en.wikipedia.org/wiki/List_of_JVM_languages – Archie Feb 20 '13 at 16:24
  • @delnan You are correct, but the important part is that it can be used (with extra code) as a VM. There are several front-ends for LLVM (such as clang), and I want to be able to leverage them. Thus, if I have an embedded VM, I can support any language that has a frontend. – Abe Schneider Feb 20 '13 at 17:00
  • @Archie Unfortunately the JVM is too difficult to interface with c++. I know it can be done -- I've done in the past. It's not something I care to repeat. However, it does look like libJIT was inspired by the JVM. – Abe Schneider Feb 20 '13 at 17:01
  • @AbeSchneider I really doubt you can re-use a LLVM-based language implementation easily. Embedding support should be virtually non-existing for most of them, let alone support for interop with LLVM IR coming from somewhere else. Of course, any language implementation that isn't totally broken and offers an API you can talk to is usable to some degree, but if the JVM is too complex to use, so are (probably) most language implementations atop of LLVM. As far as I can tell, LLVM doesn't support cross-language interop or embedding significantly better than, say, x86. –  Feb 20 '13 at 17:31
  • @delnan Is there a reason you say that? All front-ends compile to the same IR, so I don't see why you wouldn't get interoperability. It should be the same thing as how multiple languages can compile to the JVM and use each other (e.g. Java, Scala, Groovy, Clojure, etc.) – Abe Schneider Feb 20 '13 at 18:05
  • @AbeSchneider JVM bytecode is at a *much* higher level than LLVM IR, and even then one needs careful engineering to guarantee interop (cf. the amount of "quirks" the Scala language and its implementation have for the sake of Java interop). As one of a million examples: A Haskell string is fundamentally differently from a `std::string`, and a Python (3) integer doesn't even have a standard C++ equivalent (it's an arbitrary precision int). In the same way, almost every other aspect not immediately handled by LLVM is implemented very differently by different VMs. Hence my comparison to x86. –  Feb 20 '13 at 18:42
  • @delnan That's fair -- I'm thinking of this in terms of an embedded system, so for all languages a c++ binding would be necessary. Thus different string types would ultimately always be converted to std::string for core library calls. The point isn't to automagically have any interpreter language work, but that the possibility exists to use the same VM (as opposed to having a Lua VM, Python VM, etc). – Abe Schneider Feb 20 '13 at 18:50
  • If you have to write all interop code yourself, then what do you gain? Probably not memory, as LLVM is rather large and many language-specific VMs are quite small. Not necessarily performance either. Embedability doesn't look good either (as I've said before). Again, I think you may be victim to the [XY problem](http://meta.stackexchange.com/q/66377). –  Feb 20 '13 at 19:05
  • @delnan The advantage is openness in terms of third parties. Someone else can come along and write the bindings for language X (assuming a frontend exists for X) to use in my environment without having the environment itself be open. It's hard for me to imagine other ways of accomplishing this. – Abe Schneider Feb 20 '13 at 19:51
  • Take a look at the Rubinius VM as well: http://rubini.us. Apart from being a self-hosted Ruby implementation, the Rubinius VM provides a nice platform for developing self-hosted languages on top of it. Naturally it is particularly well suited for dynamic scripting languages like Ruby. There's also a projects page where you can see many such languages already implemented on top of it: http://rubini.us/projects. Also, as another advantage, it is very modular and easy to get started with, and you write everything in a high-level language (Ruby). – Txus Feb 12 '14 at 15:21

0 Answers0