]>
Commit | Line | Data |
---|---|---|
223e47cc LB |
1 | Date: Sat, 18 Nov 2000 09:19:35 -0600 (CST) |
2 | From: Vikram Adve <vadve@cs.uiuc.edu> | |
3 | To: Chris Lattner <lattner@cs.uiuc.edu> | |
4 | Subject: a few thoughts | |
5 | ||
6 | I've been mulling over the virtual machine problem and I had some | |
7 | thoughts about some things for us to think about discuss: | |
8 | ||
9 | 1. We need to be clear on our goals for the VM. Do we want to emphasize | |
10 | portability and safety like the Java VM? Or shall we focus on the | |
11 | architecture interface first (i.e., consider the code generation and | |
12 | processor issues), since the architecture interface question is also | |
13 | important for portable Java-type VMs? | |
14 | ||
15 | This is important because the audiences for these two goals are very | |
16 | different. Architects and many compiler people care much more about | |
17 | the second question. The Java compiler and OS community care much more | |
18 | about the first one. | |
19 | ||
20 | Also, while the architecture interface question is important for | |
21 | Java-type VMs, the design constraints are very different. | |
22 | ||
23 | ||
24 | 2. Design issues to consider (an initial list that we should continue | |
25 | to modify). Note that I'm not trying to suggest actual solutions here, | |
26 | but just various directions we can pursue: | |
27 | ||
28 | a. A single-assignment VM, which we've both already been thinking about. | |
29 | ||
30 | b. A strongly-typed VM. One question is do we need the types to be | |
31 | explicitly declared or should they be inferred by the dynamic compiler? | |
32 | ||
33 | c. How do we get more high-level information into the VM while keeping | |
34 | to a low-level VM design? | |
35 | ||
36 | o Explicit array references as operands? An alternative is | |
37 | to have just an array type, and let the index computations be | |
38 | separate 3-operand instructions. | |
39 | ||
40 | o Explicit instructions to handle aliasing, e.g.s: | |
41 | -- an instruction to say "I speculate that these two values are not | |
42 | aliased, but check at runtime", like speculative execution in | |
43 | EPIC? | |
44 | -- or an instruction to check whether two values are aliased and | |
45 | execute different code depending on the answer, somewhat like | |
46 | predicated code in EPIC | |
47 | ||
48 | o (This one is a difficult but powerful idea.) | |
49 | A "thread-id" field on every instruction that allows the static | |
50 | compiler to generate a set of parallel threads, and then have | |
51 | the runtime compiler and hardware do what they please with it. | |
52 | This has very powerful uses, but thread-id on every instruction | |
53 | is expensive in terms of instruction size and code size. | |
54 | We would need to compactly encode it somehow. | |
55 | ||
56 | Also, this will require some reading on at least two other | |
57 | projects: | |
58 | -- Multiscalar architecture from Wisconsin | |
59 | -- Simultaneous multithreading architecture from Washington | |
60 | ||
61 | o Or forget all this and stick to a traditional instruction set? | |
62 | ||
63 | ||
64 | BTW, on an unrelated note, after the meeting yesterday, I did remember | |
65 | that you had suggested doing instruction scheduling on SSA form instead | |
66 | of a dependence DAG earlier in the semester. When we talked about | |
67 | it yesterday, I didn't remember where the idea had come from but I | |
68 | remembered later. Just giving credit where its due... | |
69 | ||
70 | Perhaps you can save the above as a file under RCS so you and I can | |
71 | continue to expand on this. | |
72 | ||
73 | --Vikram | |
74 |