Compiling E: Phases of Transformations

[Mark S. Miller]

At 10:50 AM 8/7/00 , Ken Kahn wrote:
>From: "Mark S. Miller" <markm@caplet.com>
> >
> > Language:        Kernel-E -- portable interface from virtual machine
> >                         The subset of Auditable-E that passes audit.  Seen
> >                         by debuggers and other meta-level tools.
> >
>
>Everything you wrote made sense to me until I saw "debuggers" here. Wouldn't
>someone want to debug at the level of User-E and not Kernel-E? 

Yes.  The issue is who does what part of the backward mapping.  Take Java
(please).  The JVM knows nothing about the Java source language.  The 
portable interface to the JVM is the Java bytecode language (and the other 
information in Java class files).  Java virtual machines these days 
typically compile these to platform-dependent machine instructions.  
However, they must report debugging information about ongoing computation as 
if they are interpreting JVM bytecodes.  Other portable tools above the JVM, 
like portable debuggers, then map from bytecode execution state to 
source-oriented information, like a debugger display.  

The JVM maps from machine PC to bytecode PC.  The debugger maps from 
bytecode PC to a selection on a display.  This separation allows multiple 
source languages to share a JVM, it allows a JVM to be ported to multiple 
platforms, and it allows these two dimensions to vary independently.  All 
the same can be said of ParcPlace Smalltalk, who did a better job of it.  But 
it never became nearly as well known.

So, when designing all the suggested levels of transformation, whether above 
or below the virtual machine line, we need to be clear about which backward 
mappings we require, and how feasible they are.  Yes, this won't be easy.

Again, how do Scheme and ML handle such issues these days?


         Cheers,
         --MarkM