Christopher B. Browne's Home Page
cbbrowne@acm.org

Bytecode Systems

Christopher Browne

$Id: bytecode.sgml,v 1.19 2005-12-28 14:04:23 cbbrowne Exp $

Table of Contents
1. About Bytecode

1. About Bytecode

Contrary to the hype surrounding Java and MONO , bytecode compilation is hardly a new thing. It dates back to the days of BCPL and Pascal, and possibly even further.

The general idea is that you take code written in some high level language, and rather than compiling it into "native" code for a specific hardware architecture, you compile it into a sort of "virtual assembly language," the instruction set for some sort of generic processor. This has quite a number of merits:

1.1. MONO

The MONO project represents a free software implementation of a number of components of the Microsoft .NET "platform," notably including a C# Compiler, CLI Runtime, and class libraries.

Mono Hacking Roadmap

See also Mono development platform

1.2. Why MONO? (Or why not???)

There have periodically been some rather hysterical reports and theories about the relationship between MONO, GNOME and Microsoft. Many quite wild, with rather incoherent theories as to why someone would have thought it sensible to implement MONO.

Contrary to some of the wild theories floating out on Slashdot, the reasoning has little to do with "using Microsoft code," or Microsoft Passport authentication, or anything else of the sort.

The real reasoning has to do with language. Microsoft is implementing all sorts of things as "part of .NET;" the parts MONO is looking at are:

  • A dynamic language

    The big name Ximian project is the email-and-stuff application Evolution .

    The code for it is written in C, and apparently whopping huge portions of it consist of memory management code, which, in C, must be done quite manually.

    Using a more dynamic language offering garbage collection allows the ability to not bother writing hordes of malloc() and free() calls, which would allow an application like Evolution to be both smaller and more easily and quickly written.

    Java offers garbage collection, and so resembles an answer in this regard. So also would languages such as Lisp, Smalltalk, Eiffel, and Modula3.

  • A bytecoded (perhaps JIT-compiled) platform to provide some independence of platform.

    This also would disconnect application code somewhat from the deep details of the many C-based libraries of GNOME. Apparently the not-always-organized growth of libraries in GNOME has led to it becoming somewhat difficult to make concurrent use of many of the services offered.

    Again, Java offers a "JVM." A number of other languages offer language-specific bytecoding schemes that somewhat parallel this.

  • Language- and platform-independence

    One of the important characteristics of the GNOME project is that it intends to be relatively agnostic about what languages are used (in contrast with the somewhat C++-partisan KDE and Objective C-partisan GNUStep ).

    The various " bytecode execution machines" that are presently available are generally not terribly friendly to the use of multiple languages. JVM is for Java, for instance.

    There is some "never-accomplished Holy Grail" to this; witness UNCOL.

    In practice, while there are around a dozen language compilers available that could be used with Mono, nearly all code is written in C#.

In effect, MONO represents something rather like the Java platform, with the conspicuous difference that it is specifically intended to be language neutral.

Here are some links to interviews and commentary from sundry GNOME folk about what they're about:

Google

If this was useful, let others know by an Affero rating

Contact me at cbbrowne@acm.org