docs/HistoricalNotes/2000-11-18-EarlyDesignIdeas.txt

   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