6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-27 13:30:05 +00:00
Code Issues Projects Releases Wiki Activity

Added notes

Browse Source 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2001-06-24 02:01:31 +00:00
parent 364b147a0f
commit d6be43ecdd
1 changed files with 30 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
docs/HistoricalNotes/2001-06-20-.NET-Differences.txt Normal file
View File

@ -0,0 +1,30 @@
Date: Wed, 20 Jun 2001 12:32:22 -0500
From: Vikram Adve <vadve@cs.uiuc.edu>
To: Chris Lattner <lattner@cs.uiuc.edu>
Subject: .NET vs. our VM
One significant difference between .NET CLR and our VM is that the CLR
includes full information about classes and inheritance. In fact, I just
sat through the paper on adding templates to .NET CLR, and the speaker
indicated that the goal seems to be to do simple static compilation (very
little lowering or optimization). Also, the templates implementation in CLR
"relies on dynamic class loading and JIT compilation".
This is an important difference because I think there are some significant
advantages to have a much lower level VM layer, and do significant static
analysis and optimization.
I also talked to the lead guy for KAI's C++ compiler (Arch Robison) and he
said that SGI and other commercial compilers have included options to export
their *IR* next to the object code (i.e., .il files) and use them for
link-time code generation. In fact, he said that the .o file was nearly
empty and was entirely generated from the .il at link-time. But he agreed
that this limited the link-time interprocedural optimization to modules
compiled by the same compiler, whereas our approach allows us to link and
optimize modules from multiple different compilers. (Also, of course, they
don't do anything for runtime optimization).
All issues to bring up in Related Work.
--Vikram