diff options
Diffstat (limited to 'docs/HistoricalNotes/2000-11-18-EarlyDesignIdeas.txt')
| -rw-r--r-- | docs/HistoricalNotes/2000-11-18-EarlyDesignIdeas.txt | 74 |
1 files changed, 0 insertions, 74 deletions
diff --git a/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeas.txt b/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeas.txt deleted file mode 100644 index f086181..0000000 --- a/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeas.txt +++ /dev/null @@ -1,74 +0,0 @@ -Date: Sat, 18 Nov 2000 09:19:35 -0600 (CST) -From: Vikram Adve <vadve@cs.uiuc.edu> -To: Chris Lattner <lattner@cs.uiuc.edu> -Subject: a few thoughts - -I've been mulling over the virtual machine problem and I had some -thoughts about some things for us to think about discuss: - -1. We need to be clear on our goals for the VM. Do we want to emphasize - portability and safety like the Java VM? Or shall we focus on the - architecture interface first (i.e., consider the code generation and - processor issues), since the architecture interface question is also - important for portable Java-type VMs? - - This is important because the audiences for these two goals are very - different. Architects and many compiler people care much more about - the second question. The Java compiler and OS community care much more - about the first one. - - Also, while the architecture interface question is important for - Java-type VMs, the design constraints are very different. - - -2. Design issues to consider (an initial list that we should continue - to modify). Note that I'm not trying to suggest actual solutions here, - but just various directions we can pursue: - - a. A single-assignment VM, which we've both already been thinking about. - - b. A strongly-typed VM. One question is do we need the types to be - explicitly declared or should they be inferred by the dynamic compiler? - - c. How do we get more high-level information into the VM while keeping - to a low-level VM design? - - o Explicit array references as operands? An alternative is - to have just an array type, and let the index computations be - separate 3-operand instructions. - - o Explicit instructions to handle aliasing, e.g.s: - -- an instruction to say "I speculate that these two values are not - aliased, but check at runtime", like speculative execution in - EPIC? - -- or an instruction to check whether two values are aliased and - execute different code depending on the answer, somewhat like - predicated code in EPIC - - o (This one is a difficult but powerful idea.) - A "thread-id" field on every instruction that allows the static - compiler to generate a set of parallel threads, and then have - the runtime compiler and hardware do what they please with it. - This has very powerful uses, but thread-id on every instruction - is expensive in terms of instruction size and code size. - We would need to compactly encode it somehow. - - Also, this will require some reading on at least two other - projects: - -- Multiscalar architecture from Wisconsin - -- Simultaneous multithreading architecture from Washington - - o Or forget all this and stick to a traditional instruction set? - - -BTW, on an unrelated note, after the meeting yesterday, I did remember -that you had suggested doing instruction scheduling on SSA form instead -of a dependence DAG earlier in the semester. When we talked about -it yesterday, I didn't remember where the idea had come from but I -remembered later. Just giving credit where its due... - -Perhaps you can save the above as a file under RCS so you and I can -continue to expand on this. - ---Vikram - |