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