Lines Matching refs:we

6 Okay... here are a few of my thoughts on this (it's good to know that we
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
21    pretty expensive operation to have to do.  Additionally, we would like
25  2. Instead, we can do the following (eventually): 
27      reinventing something that we don't add much value to).  When the
36      we could sign the generated VM code with a host specific private
37      key.  Then before the code is executed/loaded, we can check to see if
47 3. By focusing on a more low level virtual machine, we have much more room
52 > 2. Design issues to consider (an initial list that we should continue
54 >    but just various directions we can pursue:
58 >    a. A single-assignment VM, which we've both already been thinking
67 Here are some other auxiliary goals that I think we should consider:
70    system.  This means that we have an "ideal" division of labor between
74 2. Portability to different processors.  Since we are most familiar with
76    we get that far...
84      with languages that don't.  As a base point, we could insist on
87 >    b. A strongly-typed VM.  One question is do we need the types to be
100 >    c. How do we get more high-level information into the VM while keeping
106    C. In the model I was thinking of (subject to change of course), we
114    mentioned above was the example of loading java bytecodes, but we want
124    calculated, etc... we would have to determine what is reasonable.  This
151 that we are seeing supports this greatly:
179 > of a dependence DAG earlier in the semester.  When we talked about
188 I think it makes sense to do so when we get our ideas more formalized and
191 not want to do all of the stuff that I pointed out above... be we will
192 want to design the project so that we do not artificially limit ourselves