200 lines · plain
1Date: Sun, 19 Nov 2000 16:23:57 -0600 (CST)2From: Chris Lattner <sabre@nondot.org>3To: Vikram Adve <vadve@cs.uiuc.edu>4Subject: Re: a few thoughts5 6Okay... here are a few of my thoughts on this (it's good to know that we7think so alike!):8 9> 1. We need to be clear on our goals for the VM. Do we want to emphasize10> portability and safety like the Java VM? Or shall we focus on the11> architecture interface first (i.e., consider the code generation and12> processor issues), since the architecture interface question is also13> important for portable Java-type VMs?14 15I forsee the architecture looking kinda like this: (which is completely16subject to change)17 181. The VM code is NOT guaranteed safe in a java sense. Doing so makes it19 basically impossible to support C like languages. Besides that,20 certifying a register based language as safe at run time would be a21 pretty expensive operation to have to do. Additionally, we would like22 to be able to statically eliminate many bounds checks in Java23 programs... for example.24 25 2. Instead, we can do the following (eventually): 26 * Java bytecode is used as our "safe" representation (to avoid27 reinventing something that we don't add much value to). When the28 user chooses to execute Java bytecodes directly (ie, not29 precompiled) the runtime compiler can do some very simple30 transformations (JIT style) to convert it into valid input for our31 VM. Performance is not wonderful, but it works right.32 * The file is scheduled to be compiled (rigorously) at a later33 time. This could be done by some background process or by a second34 processor in the system during idle time or something...35 * To keep things "safe" ie to enforce a sandbox on Java/foreign code,36 we could sign the generated VM code with a host specific private37 key. Then before the code is executed/loaded, we can check to see if38 the trusted compiler generated the code. This would be much quicker39 than having to validate consistency (especially if bounds checks have40 been removed, for example)41 42> This is important because the audiences for these two goals are very43> different. Architects and many compiler people care much more about44> the second question. The Java compiler and OS community care much more45> about the first one.46 473. By focusing on a more low level virtual machine, we have much more room48 for value add. The nice safe "sandbox" VM can be provided as a layer49 on top of it. It also lets us focus on the more interesting compilers50 related projects.51 52> 2. Design issues to consider (an initial list that we should continue53> to modify). Note that I'm not trying to suggest actual solutions here,54> but just various directions we can pursue:55 56Understood. :)57 58> a. A single-assignment VM, which we've both already been thinking59> about.60 61Yup, I think that this makes a lot of sense. I am still intrigued,62however, by the prospect of a minimally allocated VM representation... I63think that it could have definite advantages for certain applications64(think very small machines, like PDAs). I don't, however, think that our65initial implementations should focus on this. :)66 67Here are some other auxiliary goals that I think we should consider:68 691. Primary goal: Support a high performance dynamic compilation70 system. This means that we have an "ideal" division of labor between71 the runtime and static compilers. Of course, the other goals of the72 system somewhat reduce the importance of this point (f.e. portability73 reduces performance, but hopefully not much)742. Portability to different processors. Since we are most familiar with75 x86 and solaris, I think that these two are excellent candidates when76 we get that far...773. Support for all languages & styles of programming (general purpose78 VM). This is the point that disallows java style bytecodes, where all79 array refs are checked for bounds, etc...804. Support linking between different language families. For example, call81 C functions directly from Java without using the nasty/slow/gross JNI82 layer. This involves several subpoints:83 A. Support for languages that require garbage collectors and integration84 with languages that don't. As a base point, we could insist on85 always using a conservative GC, but implement free as a noop, f.e.86 87> b. A strongly-typed VM. One question is do we need the types to be88> explicitly declared or should they be inferred by the dynamic89> compiler?90 91 B. This is kind of similar to another idea that I have: make OOP92 constructs (virtual function tables, class heirarchies, etc) explicit93 in the VM representation. I believe that the number of additional94 constructs would be fairly low, but would give us lots of important95 information... something else that would/could be important is to96 have exceptions as first class types so that they would be handled in97 a uniform way for the entire VM... so that C functions can call Java98 functions for example...99 100> c. How do we get more high-level information into the VM while keeping101> to a low-level VM design?102> o Explicit array references as operands? An alternative is103> to have just an array type, and let the index computations be104> separate 3-operand instructions.105 106 C. In the model I was thinking of (subject to change of course), we107 would just have an array type (distinct from the pointer108 types). This would allow us to have arbitrarily complex index109 expressions, while still distinguishing "load" from "Array load",110 for example. Perhaps also, switch jump tables would be first class111 types as well? This would allow better reasoning about the program.112 1135. Support dynamic loading of code from various sources. Already114 mentioned above was the example of loading java bytecodes, but we want115 to support dynamic loading of VM code as well. This makes the job of116 the runtime compiler much more interesting: it can do interprocedural117 optimizations that the static compiler can't do, because it doesn't118 have all of the required information (for example, inlining from119 shared libraries, etc...)120 1216. Define a set of generally useful annotations to add to the VM122 representation. For example, a function can be analysed to see if it123 has any sideeffects when run... also, the MOD/REF sets could be124 calculated, etc... we would have to determine what is reasonable. This125 would generally be used to make IP optimizations cheaper for the126 runtime compiler...127 128> o Explicit instructions to handle aliasing, e.g.s:129> -- an instruction to say "I speculate that these two values are not130> aliased, but check at runtime", like speculative execution in131> EPIC?132> -- or an instruction to check whether two values are aliased and133> execute different code depending on the answer, somewhat like134> predicated code in EPIC135 136These are also very good points... if this can be determined at compile137time. I think that an epic style of representation (not the instruction138packing, just the information presented) could be a very interesting model139to use... more later...140 141> o (This one is a difficult but powerful idea.)142> A "thread-id" field on every instruction that allows the static143> compiler to generate a set of parallel threads, and then have144> the runtime compiler and hardware do what they please with it.145> This has very powerful uses, but thread-id on every instruction146> is expensive in terms of instruction size and code size.147> We would need to compactly encode it somehow.148 149Yes yes yes! :) I think it would be *VERY* useful to include this kind150of information (which EPIC architectures *implicitly* encode. The trend151that we are seeing supports this greatly:152 1531. Commodity processors are getting massive SIMD support:154 * Intel/Amd MMX/MMX2155 * AMD's 3Dnow!156 * Intel's SSE/SSE2157 * Sun's VIS1582. SMP is becoming much more common, especially in the server space.1593. Multiple processors on a die are right around the corner.160 161If nothing else, not designing this in would severely limit our future162expansion of the project...163 164> Also, this will require some reading on at least two other165> projects:166> -- Multiscalar architecture from Wisconsin167> -- Simultaneous multithreading architecture from Washington168>169> o Or forget all this and stick to a traditional instruction set?170 171Heh... :) Well, from a pure research point of view, it is almost more172attactive to go with the most extreme/different ISA possible. On one axis173you get safety and conservatism, and on the other you get degree of174influence that the results have. Of course the problem with pure research175is that often times there is no concrete product of the research... :)176 177> BTW, on an unrelated note, after the meeting yesterday, I did remember178> that you had suggested doing instruction scheduling on SSA form instead179> of a dependence DAG earlier in the semester. When we talked about180> it yesterday, I didn't remember where the idea had come from but I181> remembered later. Just giving credit where its due...182 183:) Thanks. 184 185> Perhaps you can save the above as a file under RCS so you and I can186> continue to expand on this.187 188I think it makes sense to do so when we get our ideas more formalized and189bounce it back and forth a couple of times... then I'll do a more formal190writeup of our goals and ideas. Obviously our first implementation will191not want to do all of the stuff that I pointed out above... be we will192want to design the project so that we do not artificially limit ourselves193at sometime in the future...194 195Anyways, let me know what you think about these ideas... and if they sound196reasonable...197 198-Chris199 200