[Vm-dev] VM Recipe: How to build an interpreter VM on Linux

David T. Lewis lewis at mail.msen.com
Sun Feb 7 22:24:30 UTC 2016

On Sat, Feb 06, 2016 at 05:21:32PM -0500, Phil (list) wrote:
> David,
> On Sun, 2015-04-12 at 22:57 -0400, David T. Lewis wrote:
> > ??
> > How to build an interpreter VM from source on a typical Linux or Unix
> > system:
> > 
> How does the interpreter VM differ from the stack VM in the Cog branch?
> ??I'm familiar with what Cog and Spur bring to the table, but not how
> these older VMs differ. (or for that matter if I should even be
> considering these VMs 'older'... are there situations where they are
> still recommended on platforms where Cog, and now Spur, are supported?)
> Thanks,
> Phil

Cl??ment's reply gives an excellent explanation of the difference, and
Eliot's blog at http://www.mirandabanda.org/cogblog/ provides a wealth of
in-depth information and explanations.

Functionally, you will not see much difference between a context interpreter
VM and a stack interpreter VM. They are the same with respect to supporting
closures and all of the latest primitives and plugins. The stack interpreter
(and Cog and Spur, which are build upon the stack interpreter) provides
support for high performance profiling. The context interpreter provides
support for older image formats, and can be easily compiled as a 64-bit
executable. But these are probably not important differences for most
people. So in a nutshell - the interpreter VM is simpler, and Cog and Spur
VMs provide higher performance. All of them work very well.

I assume that you are compiling your own VM (based on earlier questions on
the Cuis list), so here is my advice: Try compiling both Cog and an interpreter
VM. Once you get the 32-bit build environment set up, the Cog build should
be problem free. Then install CMake and follow the "recipe" for an interpreter
VM. That should be simple on a 64-bit platform, and will give you the 64-bit
VM for 32-bit images that you were asking about in the earlier thread.


More information about the Vm-dev mailing list