New interpreter breakout mechanism

Introduce parallel handler entry points for mterp interpreters as a step
towards fully supporting debug, profile and JIT within mterp (instead of
bailing out to the portable debug interpreter).

This CL contains most of the structural changes that need to happen,
but does not yet enable the new switch mode.  In short, within the
mterp assembly interpreter register rIBASE points to an array of handlers
for Dalvik opcodes.  Instead of periodically checking for suspend,
debug, profiling and JIT trace selection breakouts, rIBASE may simply
be altered to point to the parallel breakout handlers when control needs
to be rerouted.  This will enable us to eliminate the separate portable
debug interpreter and the entire mechanism of switching between the fast
and portable interpreters.

The x86 implementation required a large number of changes because of the
need to dedicate a register to holding the table base.  It will now use %edx
(which was previously scratch).

Changes include:

  o Support for two styles of mterp assembly code generation: computed goto
    and jump table (ARM uses computed goto, x86 uses jump table)
  o New mterp config operators to trigger generation of alternate entry points.
  o Alternate entries route execution through new dvmCheckInst().  That's
    where the checking code will go.
  o For x86, reserved register edx as dedicated rIBASE.
  o For jump-table mterps, ignore "%break" operator and allow variable-sized
    handlers with no "sister" region.

Note that the x86-atom implementation will need substantial changes
to function in this new model.

Change-Id: I3a22048adb7dcfdeba4f94fbb977b26c3ab2fcb3

1 files changed, 43 insertions, 11 deletions

diff --git a/vm/mterp/README.txt b/vm/mterp/README.txt
index 9e28ebca5..c5537d7c3 100644
--- a/vm/mterp/README.txt
+++ b/vm/mterp/README.txt
@@ -36,13 +36,17 @@ and testing, and to provide a way to use architecture-specific versions of
 some operations (e.g. making use of PLD instructions on ARMv6 or avoiding
 CLZ on ARMv4T).
 
-Two basic assumptions are made about the operation of the interpreter:
-
- - The assembly version uses fixed-size areas for each instruction
-   (e.g. 64 bytes).  "Overflow" code is tacked on to the end.
- - When a C implementation is desired, the assembly version packs all
-   local state into a "glue" struct, and passes that into the C function.
-   Updates to the state are pulled out of the "glue" on return.
+Depending on architecture, instruction-to-instruction transitions may
+be done as either computed goto or jump table.  In the computed goto
+variant, each instruction handler is allocated fixed-size area (e.g. 64
+byte).  "Overflow" code is tacked to the end.  In the jump table variant,
+all of the instructions handlers are contiguous and may be of any size.
+The interpreter style is selected via the "handler-size" command (see below).
+
+When a C implementation for an instruction is desired, the assembly
+version packs all local state into the Thread structure and passes
+that to the C function.  Updates to the state are pulled out of
+"Thread" on return.
 
 The "arch" value should indicate an architecture family with common
 programming characteristics, so "armv5te" would work for all ARMv5TE CPUs,
@@ -61,7 +65,9 @@ The commands are:
   handler-size <bytes>
 
     Specify the size of the assembly region, in bytes.  On most platforms
-    this will need to be a power of 2.
+    this will need to be a power of 2.  A handler-size of 0 denotes a
+    special case in which a jump table will be generated, rather than
+    a computed-goto target block.
 
   import <filename>
 
@@ -94,9 +100,27 @@ The commands are:
     opcodes are emitted when this is seen, followed by any code that
     didn't fit inside the fixed-size instruction handler space.
 
-
-The order of "op" directives is not significant; the generation tool will
-extract ordering info from the VM sources.
+  alt-op-start <directory>
+  alt <opcode> <directory>
+  alt-op-end
+
+    These three commands operate similar - but not identical - to op-start,
+    op and op-end.  When present, they will cause the generation of an
+    alternate opcode handler table.  This table is intended to be swapped
+    with the normal handler table when control breaks are needed (generally
+    for use when debugging, profiling or thread-suspend).  Note some important
+    differences:
+        Unless an opcode is specifically called out with an "alt" command,
+        its body will be generated by including the assembly file ALT_STUB.S,
+        which should appear in the <directory> specified by alt-op-start.
+        Specifically called-out opcode handlers should be in files named
+        ALT_OP_<opcode>.S in the directory specified on the "alt" command.
+        At minimum, each implementation should have a generic ALT_STUB.S
+        handler and a called-out handler for the dispatch extension opcode
+        ALT_OP_DISPATCH_FF.S.
+
+The order of "op" and "alt" directives are not significant; the generation
+tool will extract ordering info from the VM sources.
 
 Typically the form in which most opcodes currently exist is used in
 the "op-start" directive.  For a new port you would start with "c",
@@ -112,6 +136,13 @@ is emitted, a "glue stub" is emitted in the assembly source file.
 instructions, unless "asm-stub" was left blank, in which case it only
 emits some labels.)
 
+In general, the actual implementation of an opcode handler should appear
+only in the handler table created by op-start, op and op-end.  The control
+intercept stubs used by alt-op-start, alt and alt-op-end should handle
+any necessary inter-instruction bookeeping and then route to the real handlers
+in the primary table.
+
+
 
 ==== Instruction file format ====
 
@@ -160,6 +191,7 @@ Some generator operations are available.
     Identifies the split between the main portion of the instruction
     handler (which must fit in "handler-size" bytes) and the "sister"
     code, which is appended to the end of the instruction handler block.
+    In jump table implementations, %break is ignored.
 
   %verify "message"