Microsoft's C# (Sharp) & .NET -- A Heads Up

[Edward Jason Riedy]

And Alex Martelli writes:
 - 
 - A key difference appears to be that IL is not designed for easy
 - interpretation, but rather specifically for compilation down to 
 - machine-code (possibly JIT, possibly at assembly-installation time, 
 - that could be an administrative choice).

Somewhere I saw three choices: JIT, load-time, and installation 
time.  Unfortunately, they seem to be lacking the one in which I'm 
interested, namely any time.  Dynamic compilation combined with 
stochastic sampling for performance stats would be nice, although 
still an area of little research.

And there's no reason why the IL can't allow for fairly simple 
interpretation.  Things like annotated register transfer lists
aren't too difficult to interpret.  Add a threading annotation
to the RTL, and it should be just about as speed efficient as 
any other threaded interpreter (Forths, newer Erlang, qscheme, 
etc.).  It'll eat memory like a pig if you keep the whole IL
hanging around, but that's another story.

 - If so, then it would appear to be far closer to OSF's old and beautiful
 - project, the ANDF (Architecture-Neutral Distribution-Format), which 
 - never really got anywhere in practical terms -- maybe IL is sufficiently 
 - less ambitious, more focused, and/or better-funded than ANDF... who 
 - knows, one can hope!-)

What?  ANDF is certainly not beautiful.  It does not preserve 
the structure of the original program, but instead holds a 
sequence of symbols that are to be expanded into the target's 
machine code.  The lack of structure means most useful 
optimizations must be performed before the encoding, limiting 
the codegen ones to simple peephole optimizations.  And ANDF's 
opcode set limits it to the previous generation of processors, 
ones without simd register ops (MMX, AltiVec, etc.).  Some 
peephole optimizations could help with those, but certainly not 
with upcoming processors (VLIW, multithreaded, etc.).  And I
suppose you could reverse-engineer a good deal of information
from the ANDF sequence, but then why not just compile straight
from source?

At the time, it was a good first step.  And ANDF did a great 
thing in demonstrating that being the full compilation target 
is not a great goal.  Current research projects (like 
www.research.ibm.com/daisy/) have taken a different route...  
They keep the structure from the original program and use a 
fast compiler back-end to generate code for far more 
architectures than ANDF could.  And they can perform much more 
intelligent optimizations.

For an indication of the amount of pain involved in ANDF, see
  http://www.ri.silicomp.fr/andf/CmdAndLib-v10.ps
The other papers there are also good, including the ones about
Java and ANDF.  The folks at ex-OSF Grenoble produced one of 
the fastest early Java platforms using bytecode-to-ANDF 
expansion.  However, the dynamic compilation environment from 
Self (Hotspot) has gone further than the ANDF methods could by 
using the semantics of the bytecode language.

(Given your background, you probably know a great deal of this,
likely more than I do, but I still can't let an ANDF-is-nice
reference pass.)

The tiny bit of content released so far about the IL makes me 
pretty hopeful.  If it's moderately in the direction it seems to
be, MS could do the research community a great service by 
releasing it under a free license.  They won't, I'm sure, but I
can hope.

 - [...] retargeting Java compilers for it, while quite feasible, would then 
 - not be a snap, nor is all of that huge mass of Java code going to be 
 - recompiled all that easily, I suspect...

Depending on the structure of the IL, it could be as easy as 
retargeting the Java JIT to the IL, which will then be hit by
the IL JIT.  After getting the rest of Java implemented, of 
course, but the managed C++ and C versions of MS's tools could 
help that greatly.  Given MS seems to hold quite a grudge against 
Java, I'd expect to see a JVM on top of the IL pretty quickly.  
The first gen tools will likely be direct compilations to IL of 
their previous C(++?)-based JVMs, so they won't be too impressive.  
Later generations could be very nice indeed.

Bringing this back to Python...  Python could well end up running
as fast as any other dynamic language.  Add to that a migration
path from Perl, Java, etc. to Python (via CLS use of `legacy'
packages in other languages)...

Jason, thinking MS could actually get this one right, or at the
very least spur someone else into getting it right...