Preface

avram is a virtual machine code interpreter. It reads an input file containing a user-supplied application expressed in virtual machine code, and executes it on the host machine. The name is a quasi-acronym for “Applicative ViRtuAl Machine”. Notable features are

• strong support for functional programming operations (e.g., list processing)
• interfaces to selected functions from mathematical libraries, such as
  • gsl (numerical integration, differentiation, and series acceleration)

    http://www.gnu.org/software/gsl/

  • mpfr (arbitrary precision arithmetic)

    http://www.mpfr.org

  • minpack (non-linear optimization)

    http://www.netlib.org/minpack

  • lapack (linear algebra)

    http://www.netlib.org/lapack

  • fftw (fast fourier transforms)

    http://www.fftw.org

  • Rmath (statistical and transcendental functions)

    http://www.r-project.org

  • ufsparse (sparse matrices)

    http://www.cise.ufl.edu/research/sparse/SuiteSparse/current/SuiteSparse/

  • glpk (linear programming by the simplex method)

    http://www.gnu.org/software/glpk

  • lpsolve (mixed integer linear programming)

    http://sourceforge.net/projects/lpsolve/

  • kinsol (constrained non-linear optimization)

    http://www.llnl.gov/CASC/sundials/

• interoperability of virtual code applications with other console applications or shells through the expect library
• a simple high-level interface to files, environment variables and command line parameters
• support for various styles of stateless or persistent stream processors (a.k.a. Unix filters)

The reason for writing avram was that I wanted to do some work using a functional programming language, didn’t like any functional programming languages that already existed, and felt that it would be less trouble to write a virtual machine emulator than the back end of a compiler. As of version 0.1.0, the first public release of avram as such in 2000, most of the code base had been in heavy use by me for about four years, running very reliably. At this writing some six years later, it has seen even more use with rarely any reliability issues, in some cases attacking large combinatorial problems for weeks or months at a time. These problems have involved both long running continuous execution, and batches of thousands of shorter jobs.

Although the virtual machine is biased toward functional programming, it is officially language agnostic, so avram may be useful to anyone involved in the development of compilers for other programming, scripting, or special purpose languages. The crucial advantage of using it in your own project is that rather than troubling over address modes, register allocation, and other hassles inherent in generating native code, your compiler can just dump a fairly high level intermediate code representation of the source text to a file, and let the virtual machine emulator deal with the details. The tradeoff for using a presumably higher level interpreted language is that the performance is unlikely to be competitive with native code, but this issue is mitigated in the case of numerical applications whose heavy lifting is done by the external libraries mentioned above.

Portability is an added bonus. The virtual code is binary compatible across all platforms. Versions of avram as of 0.1.0 and later are packaged using GNU autotools and should be possible to build on any platform supporting them. In particular, the package is known to have built successfully on MacOS, FreeBSD, Solaris (thanks to the compile farm at Sourceforge.net) Digital Unix, and Debian GNU/Linux for i386 and Alpha platforms, although it has not been extensively tested on all of them. Earlier versions were compiled and run successfully on Irix and even Windows-NT (with gcc).

This document is divided into three main parts, with possibly three different audiences, but they all depend on a basic familiarity with Unix or GNU/Linux systems.

User Manual

essentially reproduces the information found in the manpage that is distributed with avram with a few extra examples and longer explanations. Properly deployed, avram should be almost entirely hidden from end users by wrapper scripts, so the “users” to whom this part is relevant would be those involved in preparing these scripts (a matter of choosing the right command line options). Depending on the extent to which this task is automated by a compiler, that may include the compiler writer or the developers of applications.

Virtual Machine Specification

documents much of what one would need to know in order to write a compiler that generates code executable by avram. That includes the complete virtual machine code semantics and file formats. It would also be possible to implement a compatible replacement for avram from scratch based on the information in this chapter, in case anyone has anything against C, my coding style, or the GPL. (A few patches to make it lint cleanly or a new implementation in good pedagogical Java without pointers would both be instructive exercises. ;-))

Library Reference

includes documentation on the application program interface and recommended entry points for the C library distributed with avram. This information would be of use to those wishing to develop applications incorporating similar features, or to reuse the code for unrelated purposes. It might also be useful to anyone wishing to develop C or C++ applications that read or write data files in the format used by avram.

This document was generated on November 8, 2012 using texi2html 1.82.