mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-11-01 00:11:00 +00:00
75 lines
3.3 KiB
Plaintext
75 lines
3.3 KiB
Plaintext
|
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
|
||
|
|
|