Return to vmgen.texi CVS log

Up to [gforth] / gforth / doc

changed mailing list address in README
started working on vmgen documentation

    1: @include version.texi
    2: 
    3: @c @ifnottex
    4: This file documents vmgen (Gforth @value{VERSION}).
    5: 
    6: @section Introduction
    7: 
    8: Vmgen is a tool for writing efficient interpreters.  It takes a simple
    9: virtual machine description and generates efficient C code for dealing
   10: with the virtual machine code in various ways (in particular, executing
   11: it).  The run-time efficiency of the resulting interpreters is usually
   12: within a factor of 10 of machine code produced by an optimizing
   13: compiler.
   14: 
   15: The interpreter design strategy supported by vmgen is to divide the
   16: interpreter into two parts:
   17: 
   18: @itemize @bullet
   19: 
   20: @item The @emph{front end} takes the source code of the language to be
   21: implemented, and translates it into virtual machine code.  This is
   22: similar to an ordinary compiler front end; typically an interpreter
   23: front-end performs no optimization, so it is relatively simple to
   24: implement and runs fast.
   25: 
   26: @item The @emph{virtual machine interpreter} executes the virtual
   27: machine code.
   28: 
   29: @end itemize
   30: 
   31: Such a division is usually used in interpreters, for modularity as well
   32: as for efficiency reasons.  The virtual machine code is typically passed
   33: between front end and virtual machine interpreter in memory, like in a
   34: load-and-go compiler; this avoids the complexity and time cost of
   35: writing the code to a file and reading it again.
   36: 
   37: A @emph{virtual machine} (VM) represents the program as a sequence of
   38: @emph{VM instructions}, following each other in memory, similar to real
   39: machine code.  Control flow occurs through VM branch instructions, like
   40: in a real machine.
   41: 
   42: In this setup, vmgen can generate most of the code dealing with virtual
   43: machine instructions from a simple description of the virtual machine
   44: instructions (@pxref...), in particular:
   45: 
   46: @table @emph
   47: 
   48: @item VM instruction execution
   49: 
   50: @item VM code generation
   51: Useful in the front end.
   52: 
   53: @item VM code decompiler
   54: Useful for debugging the front end.
   55: 
   56: @item VM code tracing
   57: Useful for debugging the front end and the VM interpreter.  You will
   58: typically provide other means for debugging the user's programs at the
   59: source level.
   60: 
   61: @item VM code profiling
   62: Useful for optimizing the VM insterpreter with superinstructions
   63: (@pxref...).
   64: 
   65: @end table
   66: 
   67: VMgen supports efficient interpreters though various optimizations, in
   68: particular
   69: 
   70: @itemize
   71: 
   72: @item Threaded code
   73: 
   74: @item Caching the top-of-stack in a register
   75: 
   76: @item Combining VM instructions into superinstructions
   77: 
   78: @item
   79: Replicating VM (super)instructions for better BTB prediction accuracy
   80: (not yet in vmgen-ex, but already in Gforth).
   81: 
   82: @end itemize
   83: 
   84: As a result, vmgen-based interpreters are only about an order of
   85: magintude slower than native code from an optimizing C compiler on small
   86: benchmarks; on large benchmarks, which spend more time in the run-time
   87: system, the slowdown is often less (e.g., the slowdown over the best JVM
   88: JIT compiler we measured is only a factor of 2-3 for large benchmarks
   89: (and some other JITs were slower than our interpreter).
   90: 
   91: VMs are usually designed as stack machines (passing data between VM
   92: instructions on a stack), and vmgen supports such designs especially
   93: well; however, you can also use vmgen for implementing a register VM and
   94: still benefit from most of the advantages offered by vmgen.
   95: 
   96: @section Why interpreters?
   97: