[virtmach] Virtual Machines and Code Representation

[Reuben Thomas]

On Mon, 24 Jul 2000, John R Levine wrote:

> If you restrict your target machines to byte-addressed twos-complement
> machines with 8 bit bytes and ASCII-ish character codes, which is
> indeed the majority of computers around today, and your input
> languages to ones that are sort of like C, you can be somewhat
> successful.

And given UNCOL's failure and the commonness of these machines, it's very
wise to aim at such a restricted target.

>  -- Support Fortran as a source language, taking advantage of all of the=
=20
>     semantic restrictions that permit optimization, e.g., you can assume
>     that arguments to a routine never alias each other nor any visible
>     global static data.  Don't forget EQUIVALENCE which lets you overlay
>     different types of data.

I don't see any problems with sorting out aliasing (Mite is register
based, and registers can't alias each other, as they can't be indirectly
addressed).

>  -- Support Common Lisp as a source language, with all of its data types,
>     incremental compilation, and sophisticated garbage collection (mark
>     and sweep is unlikely to be adequate)

The published version of Mite does not support stack-walking garbage
collection, but I've designed a mechanism for this, which is in the
current draft of my thesis.

>  -- Support Cobol as a source language, particularly PICTURE data which
>  -- Support C++ and Smalltalk as source languages, both of which need lot=
s

I don't see any more problem doing this than on any real machine (since
Mite is so low level).

> Once you've done that, support target architectures like the two Unisys
> mainframe lines, one of which is 36 bit word addressed, the other 48 bit =
word
> or character addressed.=20

No chance. Mite is 32-bit or 64-bit (and the code is portable between the
two). It might be possible to do this in a restricted way, but the
treatment of e.g. constants would either be much nastier, or not as
efficient.

> This is the swamp that every UNCOL has sunk into after initial
> promising looking results.  Don't go there unless you've thoroughly
> researched why all the previous attempts sank and have a clear idea
> how you will remain afloat where nobody has before.

Mostly by

1. Not trying to attack as general a problem. Mite is just an abstraction
layer for the processor and procedure calls.

2. Not trying to provide a complete solution: you'd have to add a lot to
Mite to get something with the same scope as ANDF (and they really have
completely different goals).

3. Leaving as many of the tradeoffs as possible between portability,
efficiency and generality (i.e. support of different machines and
languages) in the hands of the compiler writer. This was a major design
goal, and doesn't often seem to be.

--=20
http://sc3d.org/rrt/
L'art des vers est de transformer en beaut=E9s les faiblesses (Aragon)