diff --git a/src/tech/dalvik/dalvik-bytecode.html b/src/tech/dalvik/dalvik-bytecode.html
index 35fa64b..66c9c48 100644
--- a/src/tech/dalvik/dalvik-bytecode.html
+++ b/src/tech/dalvik/dalvik-bytecode.html
@@ -24,8 +24,13 @@
     such as (but not limited to) the program counter and a reference to the
     <code>.dex</code> file that contains the method.
   </li>
-  <li>Registers are 32 bits wide. Adjacent register pairs are used for 64-bit
-    values.
+  <li>When used for bit values (such as integers and floating point
+    numbers), registers are considered 32 bits wide. Adjacent register
+    pairs are used for 64-bit values. There is no alignment requirement
+    for register pairs.
+  </li>
+  <li>When used for object references, registers are considered wide enough
+    to hold exactly one such reference.
   </li>
   <li>In terms of bitwise representation, <code>(Object) null == (int)
     0</code>.
@@ -52,19 +57,24 @@
   reasonably common, many instructions are limited to only addressing
   the first 16
   registers. When reasonably possible, instructions allow references to
-  up to the first 256 registers. In cases where an instruction variant isn't
+  up to the first 256 registers. In addition, some instructions have variants
+  that allow for much larger register counts, including a pair of catch-all
+  <code>move</code> instructions that can address registers in the range
+  <code>v0</code> &ndash; <code>v65535</code>.
+  In cases where an instruction variant isn't
   available to address a desired register, it is expected that the register
   contents get moved from the original register to a low register (before the
   operation) and/or moved from a low result register to a high register
   (after the operation).
 </li>
 <li>There are several "pseudo-instructions" that are used to hold
-  variable-length data referred to by regular instructions (for example,
+  variable-length data payloads, which are referred to by regular
+  instructions (for example,
   <code>fill-array-data</code>). Such instructions must never be
   encountered during the normal flow of execution. In addition, the
   instructions must be located on even-numbered bytecode offsets (that is,
   4-byte aligned). In order to meet this requirement, dex generation tools
-  should emit an extra <code>nop</code> instruction as a spacer if such an
+  must emit an extra <code>nop</code> instruction as a spacer if such an
   instruction would otherwise be unaligned. Finally, though not required,
   it is expected that most tools will choose to emit these instructions at
   the ends of methods, since otherwise it would likely be the case that
@@ -81,16 +91,18 @@
 <li>Human-syntax and mnemonics:
   <ul>
   <li>Dest-then-source ordering for arguments.</li>
-  <li>Some opcodes have a disambiguating suffix with respect to the type(s)
-    they operate on: Type-general 64-bit opcodes
-    are suffixed with <code>-wide</code>.
-    Type-specific opcodes are suffixed with their type (or a
+  <li>Some opcodes have a disambiguating name suffix to indicate the type(s)
+    they operate on:
+    <ul>
+    <li>Type-general 32-bit opcodes are unmarked.</li>
+    <li>Type-general 64-bit opcodes are suffixed with <code>-wide</code>.</li>
+    <li>Type-specific opcodes are suffixed with their type (or a
     straightforward abbreviation), one of: <code>-boolean</code>
     <code>-byte</code> <code>-char</code> <code>-short</code>
     <code>-int</code> <code>-long</code> <code>-float</code>
     <code>-double</code> <code>-object</code> <code>-string</code>
-    <code>-class</code> <code>-void</code>. Type-general 32-bit opcodes
-    are unmarked.
+    <code>-class</code> <code>-void</code>.</li>
+    </ul>
   </li>
   <li>Some opcodes have a disambiguating suffix to distinguish
     otherwise-identical operations that have different instruction layouts
@@ -99,6 +111,27 @@
     mapping with static constants in the code that generates and interprets
     executables (that is, to reduce ambiguity for humans).
   </li>
+  <li>In the descriptions here, the width of a value (indicating, e.g., the
+    range of a constant or the number of registers possibly addressed) is
+    emphasized by the use of a character per four bits of width.
+  </li>
+  <li>For example, in the instruction
+    "<code>move-wide/from16 vAA, vBBBB</code>":
+    <ul>
+    <li>"<code>move</code>" is the base opcode, indicating the base operation
+    (move a register's value).</li>
+    <li>"<code>wide</code>" is the name suffix, indicating that it operates
+    on wide (64 bit) data.</li>
+    <li>"<code>from16</code>" is the opcode suffix, indicating a variant
+    that has a 16-bit register reference as a source.</li>
+    <li>"<code>vAA</code>" is the destination register (implied by the
+    operation; again, the rule is that destination arguments always come
+    first), which must be in the range <code>v0</code> &ndash;
+    <code>v255</code>.</li>
+    <li>"<code>vBBBB</code>" is the source register, which must be in the
+    range <code>v0</code> &ndash; <code>v65535</code>.</li>
+    </ul>
+  </li>
   </ul>
 </li>
 <li>See the <a href="instruction-formats.html">instruction formats
@@ -106,6 +139,10 @@
   (listed under "Op &amp; Format") as well as details about the opcode
   syntax.
 </li>
+<li>See the <a href="dex-format.html"><code>.dex</code> file format
+  document</a> for more details about where the bytecode fits into
+  the bigger picture.
+</li>
 </ul>
 
 <h2>Summary of Instruction Set</h2>
@@ -124,7 +161,14 @@
   <td>00 10x</td>
   <td>nop</td>
   <td>&nbsp;</td>
-  <td>Waste cycles.</td>
+  <td>Waste cycles.
+    <p><b>Note:</b>
+    Data-bearing pseudo-instructions are tagged with this opcode, in which
+    case the high-order byte of the opcode unit indicates the nature of
+    the data. See "<code>packed-switch-payload</code> Format",
+    "<code>sparse-switch-payload</code> Format", and
+    "<code>fill-array-data-payload</code> Format" below.</p>
+  </td>
 </tr>
 <tr>
   <td>01 12x</td>
@@ -237,7 +281,7 @@
   <td>0d 11x</td>
   <td>move-exception vAA</td>
   <td><code>A:</code> destination register (8 bits)</td>
-  <td>Save a just-caught exception into the given register. This should
+  <td>Save a just-caught exception into the given register. This must
     be the first instruction of any exception handler whose caught
     exception is not to be ignored, and this instruction must <i>only</i>
     ever occur as the first instruction of an exception handler; anywhere
@@ -438,10 +482,12 @@
 </tr>
 <tr>
   <td>24 35c</td>
-  <td>filled-new-array {vD, vE, vF, vG, vA}, type@CCCC</td>
-  <td><code>B:</code> array size and argument word count (4 bits)<br/>
-    <code>C:</code> type index (16 bits)<br/>
-    <code>D..G, A:</code> argument registers (4 bits each)</td>
+  <td>filled-new-array {vC, vD, vE, vF, vG}, type@BBBB</td>
+  <td>
+    <code>A:</code> array size and argument word count (4 bits)<br/>
+    <code>B:</code> type index (16 bits)<br/>
+    <code>C..G:</code> argument registers (4 bits each)
+  </td>
   <td>Construct an array of the given type and size, filling it with the
     supplied contents. The type must be an array type. The array's
     contents must be single-word (that is,
@@ -466,7 +512,7 @@
 <tr>
   <td>26 31t</td>
   <td>fill-array-data vAA, +BBBBBBBB <i>(with supplemental data as specified
-    below in "<code>fill-array-data</code> Format")</i></td>
+    below in "<code>fill-array-data-payload</code> Format")</i></td>
   <td><code>A:</code> array reference (8 bits)<br/>
     <code>B:</code> signed "branch" offset to table data pseudo-instruction
     (32 bits)
@@ -515,7 +561,7 @@
 <tr>
   <td>2b 31t</td>
   <td>packed-switch vAA, +BBBBBBBB <i>(with supplemental data as
-    specified below in "<code>packed-switch</code> Format")</i></td>
+    specified below in "<code>packed-switch-payload</code> Format")</i></td>
   <td><code>A:</code> register to test<br/>
     <code>B:</code> signed "branch" offset to table data pseudo-instruction
     (32 bits)
@@ -529,7 +575,7 @@
 <tr>
   <td>2c 31t</td>
   <td>sparse-switch vAA, +BBBBBBBB <i>(with supplemental data as
-    specified below in "<code>sparse-switch</code> Format")</i></td>
+    specified below in "<code>sparse-switch-payload</code> Format")</i></td>
   <td><code>A:</code> register to test<br/>
     <code>B:</code> signed "branch" offset to table data pseudo-instruction
     (32 bits)
@@ -698,16 +744,18 @@
 </tr>
 <tr>
   <td>6e..72 35c</td>
-  <td>invoke-<i>kind</i> {vD, vE, vF, vG, vA}, meth@CCCC<br/>
+  <td>invoke-<i>kind</i> {vC, vD, vE, vF, vG}, meth@BBBB<br/>
     6e: invoke-virtual<br/>
     6f: invoke-super<br/>
     70: invoke-direct<br/>
     71: invoke-static<br/>
     72: invoke-interface
   </td>
-  <td><code>B:</code> argument word count (4 bits)<br/>
-    <code>C:</code> method index (16 bits)<br/>
-    <code>D..G, A:</code> argument registers (4 bits each)</td>
+  <td>
+    <code>A:</code> argument word count (4 bits)<br/>
+    <code>B:</code> method reference index (16 bits)<br/>
+    <code>C..G:</code> argument registers (4 bits each)
+  </td>
   <td>Call the indicated method. The result (if any) may be stored
     with an appropriate <code>move-result*</code> variant as the immediately
     subsequent instruction.
@@ -749,7 +797,7 @@
     78: invoke-interface/range
   </td>
   <td><code>A:</code> argument word count (8 bits)<br/>
-    <code>B:</code> method index (16 bits)<br/>
+    <code>B:</code> method reference index (16 bits)<br/>
     <code>C:</code> first argument register (16 bits)<br/>
     <code>N = A + C - 1</code></td>
   <td>Call the indicated method. See first <code>invoke-<i>kind</i></code>
@@ -935,7 +983,7 @@
 </tbody>
 </table>
 
-<h2><code>packed-switch</code> Format</h2>
+<h2><code>packed-switch-payload</code> Format</h2>
 
 <table class="supplement">
 <thead>
@@ -974,7 +1022,7 @@
 <p><b>Note:</b> The total number of code units for an instance of this
 table is <code>(size * 2) + 4</code>.</p>
 
-<h2><code>sparse-switch</code> Format</h2>
+<h2><code>sparse-switch-payload</code> Format</h2>
 
 <table class="supplement">
 <thead>
@@ -1014,7 +1062,7 @@
 <p><b>Note:</b> The total number of code units for an instance of this
 table is <code>(size * 4) + 2</code>.</p>
 
-<h2><code>fill-array-data</code> Format</h2>
+<h2><code>fill-array-data-payload</code> Format</h2>
 
 <table class="supplement">
 <thead>
diff --git a/src/tech/dalvik/dex-format.html b/src/tech/dalvik/dex-format.html
index cab9d4c..81c0b36 100644
--- a/src/tech/dalvik/dex-format.html
+++ b/src/tech/dalvik/dex-format.html
@@ -176,7 +176,7 @@
     used by this file, either for internal naming (e.g., type descriptors)
     or as constant objects referred to by code. This list must be sorted
     by string contents, using UTF-16 code point values (not in a
-    locale-sensitive manner).
+    locale-sensitive manner), and it must not contain any duplicate entries.
   </td>
 </tr>
 <tr>
@@ -185,7 +185,7 @@
   <td>type identifiers list. These are identifiers for all types (classes,
     arrays, or primitive types) referred to by this file, whether defined
     in the file or not. This list must be sorted by <code>string_id</code>
-    index.
+    index, and it must not contain any duplicate entries.
   </td>
 </tr>
 <tr>
@@ -194,7 +194,8 @@
   <td>method prototype identifiers list. These are identifiers for all
     prototypes referred to by this file. This list must be sorted in
     return-type (by <code>type_id</code> index) major order, and then
-    by arguments (also by <code>type_id</code> index).
+    by arguments (also by <code>type_id</code> index). The list must not
+    contain any duplicate entries.
   </td>
 </tr>
 <tr>
@@ -205,7 +206,7 @@
     list must be sorted, where the defining type (by <code>type_id</code>
     index) is the major order, field name (by <code>string_id</code> index)
     is the intermediate order, and type (by <code>type_id</code> index)
-    is the minor order.
+    is the minor order. The list must not contain any duplicate entries.
   </td>
 </tr>
 <tr>
@@ -215,8 +216,9 @@
     referred to by this file, whether defined in the file or not. This
     list must be sorted, where the defining type (by <code>type_id</code>
     index) is the major order, method name (by <code>string_id</code>
-    index) is the intermediate order, and method
-    prototype (by <code>proto_id</code> index) is the minor order.
+    index) is the intermediate order, and method prototype (by
+    <code>proto_id</code> index) is the minor order.  The list must not
+    contain any duplicate entries.
   </td>
 </tr>
 <tr>
@@ -224,7 +226,9 @@
   <td>class_def_item[]</td>
   <td>class definitions list. The classes must be ordered such that a given
     class's superclass and implemented interfaces appear in the
-    list earlier than the referring class.
+    list earlier than the referring class. Furthermore, it is invalid for
+    a definition for the same-named class to appear more than once in
+    the list.
   </td>
 </tr>
 <tr>
@@ -240,8 +244,8 @@
   <td>link_data</td>
   <td>ubyte[]</td>
   <td>data used in statically linked files. The format of the data in
-    this section is left unspecified by this document;
-    this section is empty in unlinked files, and runtime implementations
+    this section is left unspecified by this document.
+    This section is empty in unlinked files, and runtime implementations
     may use it as they see fit.
   </td>
 </tr>
@@ -270,10 +274,10 @@
 <p><b>Note:</b> At least a couple earlier versions of the format have
 been used in widely-available public software releases. For example,
 version <code>009</code> was used for the M3 releases of the
-Android platform (November-December 2007),
+Android platform (November&ndash;December 2007),
 and version <code>013</code> was used for the M5 releases of the Android
-platform (February-March 2008). In several respects, these earlier versions
-of the format differ significantly from the version described in this
+platform (February&ndash;March 2008). In several respects, these earlier
+versions of the format differ significantly from the version described in this
 document.</p>
 
 <h2><code>ENDIAN_CONSTANT</code> and <code>REVERSE_ENDIAN_CONSTANT</code></h2>
@@ -311,7 +315,7 @@
 
 <h2><code>access_flags</code> Definitions</h2>
 <h4>embedded in <code>class_def_item</code>,
-<code>field_item</code>, <code>method_item</code>, and
+<code>encoded_field</code>, <code>encoded_method</code>, and
 <code>InnerClass</code></h4>
 
 <p>Bitfields of these flags are used to indicate the accessibility and
@@ -827,7 +831,7 @@
 <p>A <i>SimpleName</i> is the basis for the syntax of the names of other
 things. The <code>.dex</code> format allows a fair amount of latitude
 here (much more than most common source languages). In brief, a simple
-name may consist of any low-ASCII alphabetic character or digit, a few
+name consists of any low-ASCII alphabetic character or digit, a few
 specific low-ASCII symbols, and most non-ASCII code points that are not
 control, space, or special characters. Note that surrogate code points
 (in the range <code>U+d800</code> &hellip; <code>U+dfff</code>) are not
@@ -1320,7 +1324,7 @@
 <p>This is a list of the entire contents of a file, in order. It
 contains some redundancy with respect to the <code>header_item</code>
 but is intended to be an easy form to use to iterate over an entire
-file. A given type may appear at most once in a map, but there is no
+file. A given type must appear at most once in a map, but there is no
 restriction on what order types may appear in, other than the
 restrictions implied by the rest of the format (e.g., a
 <code>header</code> section must appear first, followed by a
@@ -2013,7 +2017,7 @@
 </table>
 
 <h2><code>code_item</code></h2>
-<h4>referenced from <code>method_item</code></h4>
+<h4>referenced from <code>encoded_method</code></h4>
 <h4>appears in the <code>data</code> section</h4>
 <h4>alignment: 4 bytes</h4>
 
@@ -2091,7 +2095,7 @@
 <tr>
   <td>tries</td>
   <td>try_item[tries_size] <i>(optional)</i></td>
-  <td>array indicating where in the code exceptions may be caught and
+  <td>array indicating where in the code exceptions are caught and
     how to handle them. Elements of the array must be non-overlapping in
     range and in order from low to high address. This element is only
     present if <code>tries_size</code> is non-zero.
@@ -2138,8 +2142,10 @@
 <tr>
   <td>handler_off</td>
   <td>ushort</td>
-  <td>offset in bytes from the start of the associated encoded handler data
-    to the <code>catch_handler_item</code> for this entry
+  <td>offset in bytes from the start of the associated
+    <code>encoded_catch_hander_list</code> to the
+    <code>encoded_catch_handler</code> for this entry. This must be an
+    offset to the start of an <code>encoded_catch_handler</code>.
   </td>
 </tr>
 </tbody>
@@ -2253,7 +2259,7 @@
 <code>address</code> register represents the instruction offset in the
 associated <code>insns_item</code> in 16-bit code units. The
 <code>address</code> register starts at <code>0</code> at the beginning of each
-<code>debug_info</code> sequence and may only monotonically increase.
+<code>debug_info</code> sequence and must only monotonically increase.
 The <code>line</code> register represents what source line number
 should be associated with the next positions table entry emitted by
 the state machine. It is initialized in the sequence header, and may
@@ -2865,7 +2871,7 @@
 which is either defined as a member of another class, per se, or is
 anonymous but not defined within a method body (e.g., a synthetic
 inner class). Every class that has this annotation must also have an
-<code>InnerClass</code> annotation. Additionally, a class may not have
+<code>InnerClass</code> annotation. Additionally, a class must not have
 both an <code>EnclosingClass</code> and an
 <code>EnclosingMethod</code> annotation.</p>
 
@@ -2892,7 +2898,7 @@
 <p>An <code>EnclosingMethod</code> annotation is attached to each class
 which is defined inside a method body. Every class that has this
 annotation must also have an <code>InnerClass</code> annotation.
-Additionally, a class may not have both an <code>EnclosingClass</code>
+Additionally, a class must not have both an <code>EnclosingClass</code>
 and an <code>EnclosingMethod</code> annotation.</p>
 
 <table class="format">
diff --git a/src/tech/dalvik/instruction-formats.html b/src/tech/dalvik/instruction-formats.html
index d7bf690..f81b595 100644
--- a/src/tech/dalvik/instruction-formats.html
+++ b/src/tech/dalvik/instruction-formats.html
@@ -27,10 +27,17 @@
 ("<code>|</code>") interspersed to aid in reading. Uppercase letters
 in sequence from "<code>A</code>" are used to indicate fields within
 the format (which then get defined further by the syntax column). The term
-"<code>op</code>" is used to indicate the position of the eight-bit
-opcode within the format. A slashed zero ("<code>&Oslash;</code>") is
-used to indicate that all bits should be zero in the indicated
-position.</p>
+"<code>op</code>" is used to indicate the position of an eight-bit
+opcode within the format. A slashed zero
+("<code>&Oslash;</code>") is used to indicate that all bits must be
+zero in the indicated position.</p>
+
+<p>For the most part, lettering proceeds from earlier code units to
+later code units, and low-order to high-order within a code unit.
+However, there are a few exceptions to this general rule, which are
+done in order to make the naming of similar-meaning parts be the same
+across different instruction formats. These cases are noted explicitly
+in the format descriptions.</p>
 
 <p>For example, the format "<code>B|A|<i>op</i> CCCC</code>" indicates
 that the format consists of two 16-bit code units. The first word
@@ -44,7 +51,7 @@
 for the format, which is used in other documents and in code to identify
 the format.</p>
 
-<p>Format IDs consist of three characters, two digits followed by a
+<p>Most format IDs consist of three characters, two digits followed by a
 letter. The first digit indicates the number of 16-bit code units in the
 format. The second digit indicates the maximum number of registers that the
 format contains (maximum, since some formats can accomodate a variable
@@ -54,8 +61,14 @@
 format "<code>21t</code>" is of length two, contains one register reference,
 and additionally contains a branch target.</p>
 
-<p>Suggested static linking formats have an additional "<code>s</code>" suffix,
-making them four characters total.</p>
+<p>Suggested static linking formats have an additional
+"<code>s</code>" suffix, making them four characters total. Similarly,
+suggested "inline" linking formats have an additional "<code>i</code>"
+suffix. (In this context, inline linking is like static linking,
+except with more direct ties into a virtual machine's implementation.)
+Finally, a couple oddball suggested formats (e.g.,
+"<code>20bc</code>") include two pieces of data which are both
+represented in its format ID.</p>
 
 <p>The full list of typecode letters are as follows. Note that some
 forms have different sizes, depending on the format:</p>
@@ -171,13 +184,13 @@
 
 <p>Similar to the representation of constant pool indices, there are
 also suggested (optional) forms that indicate prelinked offsets or
-indices. These prelinked values include "<code>vtaboff</code>"
-(vtable offset), "<code>fieldoff</code>" (field offset), and
-"<code>iface</code>" (interface pool index).</p>
+indices. There are two types of suggested prelinked value: vtable offsets
+(indicated as "<code>vtaboff</code>") and field offsets (indicated as
+"<code>fieldoff</code>").</p>
 
 <p>In the cases where a format value isn't explictly part of the syntax
 but instead picks a variant, each variant is listed with the prefix
-"<code>[<i>X</i>=<i>N</i>]</code>" (e.g., "<code>[B=2]</code>") to indicate
+"<code>[<i>X</i>=<i>N</i>]</code>" (e.g., "<code>[A=2]</code>") to indicate
 the correspondence.</p>
 
 <h2>The Formats</h2>
@@ -193,6 +206,13 @@
 </thead>
 <tbody>
 <tr>
+  <td><i>N/A</i></td>
+  <td>00x</td>
+  <td><i><code>N/A</code></i></td>
+  <td><i>pseudo-format used for unused opcodes; suggested for use as the
+    nominal format for a breakpoint opcode</i></td>
+</tr>
+<tr>
   <td>&Oslash;&Oslash;|<i>op</i></td>
   <td>10x</td>
   <td><i><code>op</code></i></td>
@@ -227,6 +247,14 @@
   <td>goto/16</td>
 </tr>
 <tr>
+  <td>AA|<i>op</i> BBBB</td></td>
+  <td>20bc</td>
+  <td><i><code>op</code></i> AA, kind@BBBB</td>
+  <td><i>suggested format for statically determined verification errors;
+    A is the type of error and B is an index into a type-appropriate
+    table (e.g. method references for a no-such-method error)</i></td>
+</tr>
+<tr>
   <td rowspan="5">AA|<i>op</i> BBBB</td>
   <td>22x</td>
   <td><i><code>op</code></i> vAA, vBBBB</td>
@@ -292,8 +320,8 @@
 <tr>
   <td>22cs</td>
   <td><i><code>op</code></i> vA, vB, fieldoff@CCCC</td>
-  <td><i>(suggested format for statically linked field access instructions of
-    format 22c)</i>
+  <td><i>suggested format for statically linked field access instructions of
+    format 22c</i>
   </td>
 </tr>
 <tr>
@@ -325,96 +353,99 @@
   <td>const-string/jumbo</td>
 </tr>
 <tr>
-  <td>B|A|<i>op</i> CCCC G|F|E|D</td>
+  <td rowspan="3">A|G|<i>op</i> BBBB F|E|D|C</td>
   <td>35c</td>
-  <td><i>[<code>B=5</code>] <code>op</code></i> {vD, vE, vF, vG, vA},
-    meth@CCCC<br/>
-    <i>[<code>B=5</code>] <code>op</code></i> {vD, vE, vF, vG, vA},
-    type@CCCC<br/>
-    <i>[<code>B=4</code>] <code>op</code></i> {vD, vE, vF, vG},
-    <i><code>kind</code></i>@CCCC<br/>
-    <i>[<code>B=3</code>] <code>op</code></i> {vD, vE, vF},
-    <i><code>kind</code></i>@CCCC<br/>
-    <i>[<code>B=2</code>] <code>op</code></i> {vD, vE},
-    <i><code>kind</code></i>@CCCC<br/>
-    <i>[<code>B=1</code>] <code>op</code></i> {vD},
-    <i><code>kind</code></i>@CCCC<br/>
-    <i>[<code>B=0</code>] <code>op</code></i> {},
-    <i><code>kind</code></i>@CCCC
+  <td><i>[<code>A=5</code>] <code>op</code></i> {vC, vD, vE, vF, vG},
+    meth@BBBB<br/>
+    <i>[<code>A=5</code>] <code>op</code></i> {vC, vD, vE, vF, vG},
+    type@BBBB<br/>
+    <i>[<code>A=4</code>] <code>op</code></i> {vC, vD, vE, vF},
+    <i><code>kind</code></i>@BBBB<br/>
+    <i>[<code>A=3</code>] <code>op</code></i> {vC, vD, vE},
+    <i><code>kind</code></i>@BBBB<br/>
+    <i>[<code>A=2</code>] <code>op</code></i> {vC, vD},
+    <i><code>kind</code></i>@BBBB<br/>
+    <i>[<code>A=1</code>] <code>op</code></i> {vC},
+    <i><code>kind</code></i>@BBBB<br/>
+    <i>[<code>A=0</code>] <code>op</code></i> {},
+    <i><code>kind</code></i>@BBBB<br/>
+    <p><i>The unusual choice in lettering here reflects a desire to make
+    the count and the reference index have the same label as in format
+    3rc.</i></p>
   </td>
   <td>&nbsp;</td>
 </tr>
 <tr>
-  <td>B|A|<i>op</i> CCCC G|F|E|D</td>
   <td>35ms</td>
-
-  <td><i>[<code>B=5</code>] <code>op</code></i> {vD, vE, vF, vG, vA},
-    vtaboff@CCCC<br/>
-    <i>[<code>B=4</code>] <code>op</code></i> {vD, vE, vF, vG},
-    vtaboff@CCCC<br/>
-    <i>[<code>B=3</code>] <code>op</code></i> {vD, vE, vF},
-    vtaboff@CCCC<br/>
-    <i>[<code>B=2</code>] <code>op</code></i> {vD, vE},
-    vtaboff@CCCC<br/>
-    <i>[<code>B=1</code>] <code>op</code></i> {vD},
-    vtaboff@CCCC<br/>
+  <td><i>[<code>A=5</code>] <code>op</code></i> {vC, vD, vE, vF, vG},
+    vtaboff@BBBB<br/>
+    <i>[<code>A=4</code>] <code>op</code></i> {vC, vD, vE, vF},
+    vtaboff@BBBB<br/>
+    <i>[<code>A=3</code>] <code>op</code></i> {vC, vD, vE},
+    vtaboff@BBBB<br/>
+    <i>[<code>A=2</code>] <code>op</code></i> {vC, vD},
+    vtaboff@BBBB<br/>
+    <i>[<code>A=1</code>] <code>op</code></i> {vC},
+    vtaboff@BBBB<br/>
+    <p><i>The unusual choice in lettering here reflects a desire to make
+    the count and the reference index have the same label as in format
+    3rms.</i></p>
   </td>
-  <td><i>(suggested format for statically linked <code>invoke-virtual</code>
-    and <code>invoke-super</code> instructions of format 35c)</i>
+  <td><i>suggested format for statically linked <code>invoke-virtual</code>
+    and <code>invoke-super</code> instructions of format 35c</i>
   </td>
 </tr>
 <tr>
-  <td>B|A|<i>op</i> DDCC H|G|F|E</td>
-  <td>35fs</td>
-  <td><i>[<code>B=5</code>] <code>op</code></i> {vE, vF, vG, vH, vA},
-    vtaboff@CC, iface@DD<br/>
-    <i>[<code>B=4</code>] <code>op</code></i> {vE, vF, vG, vH},
-    vtaboff@CC, iface@DD<br/>
-    <i>[<code>B=3</code>] <code>op</code></i> {vE, vF, vG},
-    vtaboff@CC, iface@DD<br/>
-    <i>[<code>B=2</code>] <code>op</code></i> {vE, vF},
-    vtaboff@CC, iface@DD<br/>
-    <i>[<code>B=1</code>] <code>op</code></i> {vE},
-    vtaboff@CC, iface@DD<br/>
+  <td>35mi</td>
+  <td><i>[<code>A=5</code>] <code>op</code></i> {vC, vD, vE, vF, vG},
+    inline@BBBB<br/>
+    <i>[<code>A=4</code>] <code>op</code></i> {vC, vD, vE, vF},
+    inline@BBBB<br/>
+    <i>[<code>A=3</code>] <code>op</code></i> {vC, vD, vE},
+    inline@BBBB<br/>
+    <i>[<code>A=2</code>] <code>op</code></i> {vC, vD},
+    inline@BBBB<br/>
+    <i>[<code>A=1</code>] <code>op</code></i> {vC},
+    inline@BBBB<br/>
+    <p><i>The unusual choice in lettering here reflects a desire to make
+    the count and the reference index have the same label as in format
+    3rmi.</i></p>
   </td>
-  <td><i>(suggested format for statically linked <code>invoke-interface</code>
-    instructions of format 35c)</i>
+  <td><i>suggested format for inline linked <code>invoke-static</code>
+    and <code>invoke-virtual</code> instructions of format 35c</i>
   </td>
 </tr>
 <tr>
-  <td>AA|<i>op</i> BBBB CCCC</td>
+  <td rowspan="3">AA|<i>op</i> BBBB CCCC</td>
   <td>3rc</td>
   <td><i><code>op</code></i> {vCCCC .. vNNNN}, meth@BBBB<br/>
     <i><code>op</code></i> {vCCCC .. vNNNN}, type@BBBB<br/>
-    <p><i>(where <code>NNNN = CCCC+AA-1</code>, that is <code>A</code>
+    <p><i>where <code>NNNN = CCCC+AA-1</code>, that is <code>A</code>
     determines the count <code>0..255</code>, and <code>C</code>
-    determines the first register)</i></p>
+    determines the first register</i></p>
   </td>
   <td>&nbsp;</td>
 </tr>
 <tr>
-  <td>AA|<i>op</i> BBBB CCCC</td>
   <td>3rms</td>
   <td><i><code>op</code></i> {vCCCC .. vNNNN}, vtaboff@BBBB<br/>
-    <p><i>(where <code>NNNN = CCCC+AA-1</code>, that is <code>A</code>
+    <p><i>where <code>NNNN = CCCC+AA-1</code>, that is <code>A</code>
     determines the count <code>0..255</code>, and <code>C</code>
-    determines the first register)</i></p>
+    determines the first register</i></p>
   </td>
-  <td><i>(suggested format for statically linked <code>invoke-virtual</code>
-    and <code>invoke-super</code> instructions of format <code>3rc</code>)</i>
+  <td><i>suggested format for statically linked <code>invoke-virtual</code>
+    and <code>invoke-super</code> instructions of format <code>3rc</code></i>
   </td>
 </tr>
 <tr>
-  <td>AA|<i>op</i> CCBB DDDD</td>
-  <td>3rfs</td>
-  <td><i><code>op</code></i> {vDDDD .. vNNNN}, vtaboff@BB,
-    iface@CC<br/>
-    <p><i>(where <code>NNNN = DDDD+AA-1</code>, that is <code>A</code>
-    determines the count <code>0..255</code>, and <code>D</code>
-    determines the first register)</i></p>
+  <td>3rmi</td>
+  <td><i><code>op</code></i> {vCCCC .. vNNNN}, inline@BBBB<br/>
+    <p><i>where <code>NNNN = CCCC+AA-1</code>, that is <code>A</code>
+    determines the count <code>0..255</code>, and <code>C</code>
+    determines the first register</i></p>
   </td>
-  <td><i>(suggested format for statically linked <code>invoke-interface</code>
-    instructions of format <code>3rc</code>)</i>
+  <td><i>suggested format for inline linked <code>invoke-static</code>
+    and <code>invoke-virtual</code> instructions of format 3rc</i>
   </td>
 </tr>
 <tr>