[virtmach] Virtual Machines and Code Representation

[John R Levine]

> >  -- Support Fortran as a source language, taking advantage of all of the 
> >     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).

It's not just the registers, it's what they point to.  How can a back end 
take advantage of that?  Fortran users care.

> >  -- 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.

I think that Lisp uses "big bag of pages" and the like to encode type and 
liveness info.  The problem is that the exact implementation tends to 
depend on arcane warts of each architecture.

> >  -- Support Cobol as a source language, particularly PICTURE data which
> >  -- Support C++ and Smalltalk as source languages, both of which need lots
> 
> I don't see any more problem doing this than on any real machine (since
> Mite is so low level).

Again, the problem is that you lose the abstraction -- on a Vax or IBM 390
there are decimal arithmetic, pack/unpack, and format editing instructions
that speed up Cobol programs.  In C++ you have problems with template bloat
which often has somewhat architecture-specific solutions. 

> 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.

Well, sure, but I think you'll find that in interesting real cases you still
lose significant performance due to losing semantic info from the source
language or not knowing about useful quirks of the target.  Oh, and what if
the target machine speaks EBCDIC? 

It's certainly possible to create a virtual machine that you can port
anywhere, PICK did it over a decade ago.  The question in my mind is whether
your VM will perform well enough in its target domain that it'll be useful to
anyone.  For PICK, the slow performance of the VM didn't matter since most of
the action was in calls to a built-in database manager and screen formatter,
and PICK progams tend not to be very compute-intensive. 

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4  2D AC 1E 9E A6 36 A3 47