Initial draft of PNaCl bitcode files document.

native_client_sdk/doc_generated/reference/pnacl-bitcode-manual.html

+{{+bindTo:partials.standard_nacl_article}}
+
+<section id="pnacl-bitcode-file-reference-manual">
+<h1 id="pnacl-bitcode-file-reference-manual">PNaCl Bitcode File Reference Manual</h1>
+<div class="contents local" id="contents" style="display: none">
+<ul class="small-gap">
+<li><a class="reference internal" href="#introduction" id="id5">Introduction</a></li>
+<li><a class="reference internal" href="#data-model" id="id6">Data Model</a></li>
+<li><a class="reference internal" href="#high-level-basics" id="id7">High Level Basics</a></li>
+<li><a class="reference internal" href="#pnacl-blocks" id="id8">PNaCl Blocks</a></li>
+<li><a class="reference internal" href="#pnacl-records" id="id9">PNaCl Records</a></li>
+<li><a class="reference internal" href="#conventions-for-describing-records" id="id10">Conventions for describing records</a></li>
+<li><a class="reference internal" href="#factorial-example" id="id11">Factorial Example</a></li>
+<li><p class="first"><a class="reference internal" href="#parse-state" id="id12">Parse State</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#typing" id="id13">Typing</a></li>
+<li><a class="reference internal" href="#id-counters" id="id14">ID Counters</a></li>
+<li><a class="reference internal" href="#size-variables" id="id15">Size Variables</a></li>
+<li><a class="reference internal" href="#other-variables" id="id16">Other Variables</a></li>
+</ul>
+</li>
+<li><p class="first"><a class="reference internal" href="#special-records" id="id17">Special records</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#header-record" id="id18">Header Record</a></li>
+<li><a class="reference internal" href="#enter-block-record" id="id19">Enter Block Record</a></li>
+<li><a class="reference internal" href="#exit-block-record" id="id20">Exit Block Record</a></li>
+</ul>
+</li>
+<li><p class="first"><a class="reference internal" href="#types-block" id="id21">Types Block</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#count-record" id="id22">Count Record</a></li>
+<li><a class="reference internal" href="#void-type" id="id23">Void Type</a></li>
+<li><a class="reference internal" href="#integer-types" id="id24">Integer Types</a></li>
+<li><a class="reference internal" href="#bit-floating-type" id="id25">32-Bit Floating Type</a></li>
+<li><a class="reference internal" href="#id1" id="id26">64-bit Floating Type</a></li>
+<li><a class="reference internal" href="#vector-types" id="id27">Vector Types</a></li>
+<li><a class="reference internal" href="#function-type" id="id28">Function Type</a></li>
+</ul>
+</li>
+<li><p class="first"><a class="reference internal" href="#globals-block" id="id29">Globals block</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#id2" id="id30">Count Record</a></li>
+<li><a class="reference internal" href="#global-variable-addressses" id="id31">Global Variable Addressses</a></li>
+<li><a class="reference internal" href="#global-constant-addresses" id="id32">Global Constant Addresses</a></li>
+<li><a class="reference internal" href="#zerofill-initializer" id="id33">Zerofill Initializer</a></li>
+<li><a class="reference internal" href="#data-initializer" id="id34">Data Initializer</a></li>
+<li><a class="reference internal" href="#relocation-initializer" id="id35">Relocation Initializer</a></li>
+<li><a class="reference internal" href="#subfield-relocation-initializer" id="id36">Subfield Relocation Initializer</a></li>
+<li><a class="reference internal" href="#compound-initializer" id="id37">Compound Initializer</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#valuesymtab-block" id="id38">Valuesymtab Block</a></li>
+<li><p class="first"><a class="reference internal" href="#module-block" id="id39">Module Block</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#version" id="id40">Version</a></li>
+<li><a class="reference internal" href="#function-address" id="id41">Function Address</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#constants-blocks" id="id42">Constants Blocks</a></li>
+<li><p class="first"><a class="reference internal" href="#function-blocks" id="id43">Function Blocks</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#function-enter" id="id44">Function enter</a></li>
+<li><a class="reference internal" href="#id3" id="id45">Count Record</a></li>
+<li><p class="first"><a class="reference internal" href="#terminator-instructions" id="id46">Terminator Instructions</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#return-void-instruction" id="id47">Return Void Instruction</a></li>
+<li><a class="reference internal" href="#return-value-instruction" id="id48">Return Value Instruction</a></li>
+<li><a class="reference internal" href="#unconditional-branch-instruction" id="id49">Unconditional Branch Instruction</a></li>
+<li><a class="reference internal" href="#conditional-branch-instruction" id="id50">Conditional Branch Instruction</a></li>
+<li><a class="reference internal" href="#unreachable" id="id51">Unreachable</a></li>
+<li><a class="reference internal" href="#switch-instruction" id="id52">Switch Instruction</a></li>
+</ul>
+</li>
+<li><p class="first"><a class="reference internal" href="#integer-binary-inststructions" id="id53">Integer Binary Inststructions</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#integer-add" id="id54">Integer Add</a></li>
+<li><a class="reference internal" href="#integer-subtract" id="id55">Integer Subtract</a></li>
+<li><a class="reference internal" href="#integer-multiply" id="id56">Integer Multiply</a></li>
+<li><a class="reference internal" href="#signed-integer-divide" id="id57">Signed Integer Divide</a></li>
+<li><a class="reference internal" href="#unsigned-integer-divide" id="id58">Unsigned Integer Divide</a></li>
+<li><a class="reference internal" href="#signed-integer-remainder" id="id59">Signed Integer Remainder</a></li>
+<li><a class="reference internal" href="#unsigned-integer-remainder-instruction" id="id60">Unsigned Integer Remainder Instruction</a></li>
+<li><a class="reference internal" href="#shift-left" id="id61">Shift left</a></li>
+<li><a class="reference internal" href="#logical-shift-right" id="id62">Logical Shift right</a></li>
+<li><a class="reference internal" href="#arithmetic-shift-right" id="id63">Arithmetic Shift Right</a></li>
+<li><a class="reference internal" href="#logical-and" id="id64">Logical And</a></li>
+<li><a class="reference internal" href="#logical-or" id="id65">Logical Or</a></li>
+<li><a class="reference internal" href="#logical-xor" id="id66">Logical Xor</a></li>
+</ul>
+</li>
+<li><p class="first"><a class="reference internal" href="#floating-binary-inststructions" id="id67">Floating Binary Inststructions</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#float-add" id="id68">Float Add</a></li>
+<li><a class="reference internal" href="#float-subtract" id="id69">Float Subtract</a></li>
+<li><a class="reference internal" href="#float-multiply" id="id70">Float Multiply</a></li>
+<li><a class="reference internal" href="#float-divide" id="id71">Float Divide</a></li>
+<li><a class="reference internal" href="#float-remainder" id="id72">Float Remainder</a></li>
+</ul>
+</li>
+<li><p class="first"><a class="reference internal" href="#memory-creation-and-access-instructions" id="id73">Memory creation and access Instructions</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#alloca-instruction" id="id74">Alloca Instruction</a></li>
+<li><a class="reference internal" href="#load-instruction" id="id75">Load Instruction</a></li>
+<li><a class="reference internal" href="#store-instruction" id="id76">Store Instruction</a></li>
+</ul>
+</li>
+<li><p class="first"><a class="reference internal" href="#conversion-instructions" id="id77">Conversion Instructions</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#integer-truncating-instruction" id="id78">Integer truncating Instruction</a></li>
+<li><a class="reference internal" href="#floating-truncating-instruction" id="id79">Floating truncating Instruction</a></li>
+<li><a class="reference internal" href="#zero-extending-instruction" id="id80">Zero Extending Instruction</a></li>
+<li><a class="reference internal" href="#sign-extending-instruction" id="id81">Sign Extending Instruction</a></li>
+<li><a class="reference internal" href="#fpext" id="id82">fpext</a></li>
+<li><a class="reference internal" href="#fptoui" id="id83">fptoui</a></li>
+<li><a class="reference internal" href="#fptosi" id="id84">fptosi</a></li>
+<li><a class="reference internal" href="#sitofp" id="id85">sitofp</a></li>
+<li><a class="reference internal" href="#bitcast" id="id86">bitcast</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#comparison-instructions" id="id87">Comparison Instructions</a></li>
+<li><p class="first"><a class="reference internal" href="#other-instructions" id="id88">Other Instructions</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#phi-instruction" id="id89">Phi Instruction</a></li>
+<li><a class="reference internal" href="#forward-type-declarations" id="id90">Forward type declarations</a></li>
+<li><a class="reference internal" href="#select-instruction" id="id91">Select Instruction</a></li>
+<li><a class="reference internal" href="#call-instructions" id="id92">Call Instructions</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#intrinsic-functions" id="id93">Intrinsic Functions</a></li>
+</ul>
+</li>
+<li><p class="first"><a class="reference internal" href="#support-functions" id="id94">Support Functions</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#signrotate" id="id95">SignRotate</a></li>
+<li><a class="reference internal" href="#absoluteindex" id="id96">AbsoluteIndex</a></li>
+<li><a class="reference internal" href="#relativeindex" id="id97">RelativeIndex</a></li>
+<li><a class="reference internal" href="#abbrevindex" id="id98">AbbrevIndex</a></li>
+<li><a class="reference internal" href="#log2" id="id99">Log2</a></li>
+<li><a class="reference internal" href="#exp" id="id100">exp</a></li>
+<li><a class="reference internal" href="#bitsizeof" id="id101">BitSizeOf</a></li>
+<li><a class="reference internal" href="#underlyingtype" id="id102">UnderlyingType</a></li>
+<li><a class="reference internal" href="#underlyingcount" id="id103">UnderlyingCount</a></li>
+<li><a class="reference internal" href="#isinteger" id="id104">IsInteger</a></li>
+<li><a class="reference internal" href="#isfloat" id="id105">IsFloat</a></li>
+<li><p class="first"><a class="reference internal" href="#abbreviations" id="id106">Abbreviations</a></p>
+<ul class="small-gap">
+<li><a class="reference internal" href="#id4" id="id107">Introduction</a></li>
+<li><a class="reference internal" href="#bitstream-format" id="id108">Bitstream Format</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#reference-implementation" id="id109">Reference Implementation</a></li>
+</ul>
+</li>
+</ul>
+
+</div><section id="introduction">
+<h2 id="introduction">Introduction</h2>
+<p>This document is a reference manual for the contents of PNaCl bitcode files. It
+is presented using assembly language <em>PNaClAsm</em>. PNaClAsm uses a <em>static single
+assignment</em> (SSA) based representation that requires generated results to have a
+single (assignment) source. PNaClAsm is the textual version of the bitcode file.</p>
+<p>PNaClAsm focusses on the semantic content of the file, not the bit-encoding of
+that content. However, it does provide annotations that allow one to specify
+how the PNaCl bitcode writer converts the semantic content of a PNaClAsm
+program, into a specific bit sequence.</p>
+<p>Below PNaClAsm is the high-level form of the data stored in PNaCl bitcode
+files. Each construct in PNaClAsm defines a corresponding <em>PNaCl record</em> [ref].
+A PNaCl bitcode file is simply a sequence of PNaCl records. The goal of PNaClAsm
+is to make records easier to read, and not to define a high-level user
+programming language.</p>
+<p>PNaCl records are an abstract encoding of structured data, similar to XML. Like
+XML, PNaCl records have a notion of tags (i.e. the first element in a record,
+called a <em>code</em>), and nested structures. The nested structures are defined by
+corresponding <em>enter</em> and <em>exit</em> block records.</p>
+<p>These block records must be used like parentheses to define the block structure
+that is imposed on top of records. Each exit record must be preceded by a
+corresponding enter record. Blocks can be nested by nesting enter/exit records
+appropriately.</p>
+<p>The <em>PNaCl bitcode writer</em> takes the sequence of records, defined by a PNaClAsm
+program, and converts each record into a (variable) sequence of bits. The output
+of each bit sequence is appended together. The resulting generated sequence of
+bits is the contents of the PNaCl bitcode file.</p>
+<p>For every kind of record, there is a default method for converting records into
+bit sequences. These methods correspond to a notion of <em>abbreviations</em>
+[ref]. Each abbreviation defines a specific bit sequence conversion to be
+applied. The default conversion methods are simply predefined abbreviations.</p>
+<p>The default abbreviations can be overridden with user-specified abbreviations.
+All user-specified abbreviations are included in the generated bitcode
+file. Each abbreviation defines how a record is converted to a bit sequences. The
+<em>PNaCl bitcode writer</em> uses these abbreviations to convert the corresponding
+record sequence into a corresponding bit sequence. As a result, all records have
+an abbreviation (user or default) associated with them.</p>
+<p>The <em>PNaCl bitcode reader</em> then uses these abbreviations to convert the bit
+sequences back into the corresponding records.</p>
+<p>Conceptually, abbreviations are used to define how to pack the contents of
+records into bit sequences.  The main reason for defining abbreviations is to
+save space. The default abbreviations are simplistic and are intended to handle
+all possible records. The default abbreviations do not really worry about being
+efficient, in terms of the number of bits generated.</p>
+<p>By separating the concepts of PNaCl records and abbreviations, the notion of
+data compression is cleanly separated from semantic content. This allows
+different use cases to decide how much effort should be spent on compressing
+records.</p>
+<p>For a JIT compiler that produces bitcode, little (if any) compression should be
+applied. In fact, the API to the JIT may just be the records themselves.  The
+goal of a JIT is to perform the final translation to machine code as quickly as
+possible.  On the other hand, when delivering across the web, one may want to
+compress the sequence of bits considerably, to reduce costs in delivering web
+pages.</p>
+</section><section id="data-model">
+<h2 id="data-model">Data Model</h2>
+<p>The data model for PNaCl bitcode is fixed at little-endian ILP32: pointers are
+32 bits in size. 64-bit integer types are also supported natively via the i64
+type (for example, a front-end can generate these from the C/C++ type <em>long
+long</em>).</p>
+<p>Integers are assumed to be modeled using two&#8217;s complement.  Floating point
+support is fixed at IEEE 754 32-bit and 64-bit values (f32 and f64,
+respectively).</p>
+</section><section id="high-level-basics">
+<h2 id="high-level-basics">High Level Basics</h2>
+<p>A program is defined as a sequence of top-level <em>blocks</em>. Blocks can be nested
+within other blocks. Each block defines a sequence of records.</p>
+<p>Most of the records, within a block, also define a unique values.  Each unique
+value is given a corresponding unique identifier (i.e. <em>ID</em>). In PNaClAsm. each
+kind of block defines its own kind of identifiers. The names of these
+identifiers are defined by concatenating a prefix character (&#8216;&#64;&#8217; or &#8216;%&#8217;), the
+kind of block (a single character), and a suffix index. The suffix index is
+defined by the positional location of the defined value within the records of
+the corresponding block. The indices are all zero based, meaning that the first
+defined value (within a block) is defined using index 0.</p>
+<p>Identifiers are categorized into two types, <em>local</em> and <em>global</em>. Local
+identifiers are identifiers that are associated with the implementation of a
+single function. All other identifiers are global. This split is
+intentional. Global identifiers are used by multiple functions, and therefore
+must be unique across all function implementations. Local identifiers only apply
+to a single function, and can be reused between functions.  The <em>PNaCl
+translator</em> uses this separation to parallelize the compilation of functions.</p>
+<p>Global identifiers use the prefix character <em>&#8216;&#64;&#8217;</em> while local identifiers use
+the prefix character <em>&#8216;%&#8217;</em>.</p>
+<p>Note: There is one exception to this separation of local and global identifiers.
+Abbreviations can be defined locally and globally. An abbreviation is local if
+it only applies to the block it appears in. If it is global, the abbreviation
+can apply to multiple block instances.</p>
+<p>Note that by using positional location to define identifiers (within a block),
+the values defined in PNaCl bitcode files need not be explicitly included in the
+bitcode file. Rather, they are inferred by the (ordered) position of the record
+in the block.  This is also intentional. It is used to reduce the amount of data
+that must be (explicitly) passed to the PNaCl translator.</p>
+<p>In general, most of the records within blocks are assumed to be topologically
+sorted, putting value definitions before their uses.  This implies that records
+do not need to encode data if they can deduce the corresponding information from
+their uses.</p>
+<p>The most common use of this is that many instructions use the type of their
+operands to determine the type of the instruction. Again, this is
+intentional. It allows less information to be stored.</p>
+<p>However, for function blocks (which define instructions), no topological sort
+exists. Loop carried value dependencies simply do not allow topologically
+sorting. To deal with this, function blocks have a notion of a forward
+(instruction value) declaration. These declarations must appear before any of
+the uses of that value, if the (instruction) value is defined later in the
+function than its first use.</p>
+</section><section id="pnacl-blocks">
+<h2 id="pnacl-blocks">PNaCl Blocks</h2>
+<p>Blocks are used to organize records in the bitcode file.  The kinds of blocks
+defined in PNaClAsm are:</p>
+<dl class="docutils">
+<dt>Types block</dt>
+<dd>Defines the set of types used by the program. All types used in the program
+must be defined in this block. These types consist of primitive types as well
+as high level constructs such as vectors and function signatures.</dd>
+<dt>Globals block</dt>
+<dd>Defines the set of global addresses of global variables and constants, used by
+the program. It also defines how each global (associated with the global
+address) is initialized.</dd>
+<dt>Valuesymtab block</dt>
+<dd>Defines textual names for global and function addresses.</dd>
+<dt>Function block</dt>
+<dd>Each function (implemented) in a program has its own block that defines the
+implementation of the corresponding function.</dd>
+<dt>Constants block</dt>
+<dd>Each implemented function, that uses constants in its instructions, defines a
+constant block. Constants blocks appear within the corresponding function
+block.</dd>
+<dt>Module block</dt>
+<dd>A top-level block defining the program. This block defines global information
+used by the program, followed by function blocks defining the implementation
+of functions within the program.</dd>
+<dt>Abbreviations block</dt>
+<dd>Defines abbreviations that are used to compress PNaCl records. This block is
+segmented into multiple sections, one section for each kind of block. This
+block appears at the beginning of the module block.</dd>
+</dl>
+<p>A PNaCl program consists of a header record and a module block. The header
+defines a sequence of bytes uniquely identifying the file as a bitcode file. The
+module block defines the program to run.</p>
+<p>Each block, within a bitcode file, defines values. These values are associated
+with IDs. Each type of block defines different kinds of IDs.</p>
+<p>The <em>abbreviations block</em> [ref] is the first block in the module buld.. The
+block is divided into sections.  Each section is a sequence of records. Each
+record in the sequence defines a user-defined abbreviation.  Each section
+defines abbreviations that can be applied to all (succeeding) blocks of a
+particular kind. These abbreviations are denoted by the (global) ID of the form
+<em>&#64;aN</em>.</p>
+<p>The <em>types block</em> [ref] defines types used by the program. Each record in the
+types block defines a separate type. Valid types include various sizes of
+integer and floating types. They also define higher level constructs such as
+vectors and function signatures. For each definition, a type ID is defined. A
+type ID is of the form <em>&#64;tN</em>, where <em>N</em> corresponds to the (relative) position
+of the corresponding defining record in the types block.</p>
+<p>The types block must appear within the module block, and must appear before any
+block that uses a typed value.  Many PNaClAsm constructs allow one to use
+explicit type names, rather than type IDs. However, they are internally
+converted to the corresponding type ID in the types block. Hence, the
+requirement that the types block must appear early in the module block.</p>
+<p>The <em>module block</em> [ref] contains all other blocks.  The only values defined in
+a module block are function addresses.  All remaining definitions appear within
+blocks of the module block.</p>
+<p>Function addresses are global IDs of the form <em>&#64;fN</em>, where <em>N</em> corresponds to
+the position of the corresponding function address record in the module
+block. Function addresses must appear after the types block.</p>
+<p>The <em>globals block</em> [ref] defines global addresses for global variables and
+constants, used in the program. This block not only defines the addresses, but
+also the size of the corresponding memory associated with these addresses, and
+how the memory should be initialized.</p>
+<p>The globals block must appear in the module block, and after all function
+address records.  Global addresses (defined by the globals block) are of the
+form <em>&#64;gN</em>, where <em>N</em> is the (relative) position of the corresponding defining
+records.</p>
+<p>The <em>valuesymtab block</em> [ref] does not define any values. Rather, its only goal
+is to associate text names with previously defined global addresses
+(i.e. function, constant, and variable).  Each association is defined by a
+record in the valuesymtab block. Currently, only <em>intrinsic</em> [ref] function
+addresses need a name. All other entries in this block are considered as a hint
+for debugging. The PNaCl translator may (or may not) pass these names to the
+running executable, allowing the (runtime) debugger to associate names with
+addresses.</p>
+<p>Each <em>function block</em> [ref] defines the implementation of a single
+function. Each function block defines the intermediate representation of the
+function, consisting of basic blocks and instructions. If constants are used
+within instructions, they are defined in a <em>constants block</em>, nested within the
+corresponding function block.</p>
+<p>All function blocks are associated with a corresponding function address. This
+association is (again) positional rather than explicit. That is, the Nth
+function block in a module block corresponds to the Nth defining (rather than
+declared) function address record in the module block.</p>
+<p>Hence, within a function block, there is no explicit reference to the
+function address the block defines. For readability, PNaClAsm uses the
+corresponding function heading, associated with the corresponding
+function address record, even though that data does not appear in the
+corresponding records.</p>
+<p>Unlike other blocks, a function block defines multiple kinds of
+values: parameter, basic block, and instruction. Parameter IDs (in
+PNaClAsm) are identified using local IDs of the form <em>%pN</em>. Basic
+block IDs are identified using local IDs of the form
+<em>%bN</em>. Instructions that generate values are identified using local
+IDs of the form <em>%vN</em>.</p>
+<p>Hence, <em>%pN</em> denotes the Nth parameter of the function. <em>%bN</em> denotes
+the <em>Nth</em> basic block within the function. <em>%vN</em> denotes the value
+generated by the <em>Nth</em> instruction that generates a value. Note: <em>%vN</em>
+does not necessarily refer to the <em>Nth</em> instruction in the function
+block, because not all instructions generate values.</p>
+<p>Within a function block, basic blocks are not explicitly defined in the records
+of a function block. Rather, the first record of the block identifies how many
+basic blocks appear in the control flow graph of the function. This record is
+then followed by a sequence of records, each record defining a single
+instruction. Special <em>terminating</em> [ref] (e.g. branch) instructions are used to
+determine block boundaries.</p>
+<p>Each <em>constants block</em> [ref] defines constants that are used by the enclosing
+function block. The purpose of the constants block is to merge all uses of a
+constant (within a function) into a single defining ID.  Constant IDs are of the
+form <em>%cN</em>, where <em>N</em> corresponds to the (relative) position of the constant
+defined in the corresponding constants block.  The constants block must appear
+before any instruction.</p>
+</section><section id="pnacl-records">
+<h2 id="pnacl-records">PNaCl Records</h2>
+<p>A PNaCl record is a non-empty sequence of unsigned, 64-bit, integers. A record
+is identified by the record <em>code</em>, which is the first element in the
+sequence. Record codes are unique within a specific kind of block, but are not
+necessarily unique across different kinds of blocks. The record code acts as the
+variant discriminator (i.e. tag) within a block, to identify what kind of record
+it is.</p>
+<p>Record codes are typically small numbers. In an ideal world, they would be a
+consecutive sequence of integers, starting at zero. However, the reality is that
+PNaCl records evolved over time (and actually started as LLVM records [ref]).
+For backwards compatibility, old numbers have not been reused, leaving gaps in
+the actual record code values used.</p>
+<p>The exception of using small numbers for record codes, are four special kinds of
+records.  What makes these four kinds of records special is that they either
+apply in multiple blocks, or don&#8217;t occur in any block. To make these cases
+clear, and to leave room for lots of future growth in PNaClAsm, these special
+records have record codes close to the value 2**16. Note: Well-formed PNaCl
+bitcode files do not have record codes &gt;= 2**16.</p>
+<p>A PNaCl record is denoted as follows:</p>
+<pre class="prettyprint">
+a: &lt;v0, v1, ... , vN&gt;
+</pre>
+<p>The value <em>v0</em> is the record code. The remaining values, <em>v1</em> through <em>vN</em>, are
+parameters that fill in additional information needed by the construct it
+represents. All records must have a record code. Hence, empty PNaCl records are
+not allowed.</p>
+<p>While most records (for a given record code) are of the same length, it is not
+true of all record codes. Some record codes can have arbitrary length. In
+particular, function type signatures, call instructions, phi nodes, switch
+instructions, and global variable initialization records all have variable
+length.</p>
+<p>Records are converted to bit sequences using an abbreviation. Let <em>a</em> the the index
+identifying the abbreviation that is used to convert the record to a sequence of
+bits. If a user-defined abbreviation <em>%aA</em> (or <em>&#64;aA</em> if global) is specified in
+the syntax, then <em>a = AbbrevIndex(%aA)</em>.</p>
+<p>The PNaCl bitcode writer, which converts records to bit sequences, does this by
+writing out the abbreviation index used to encode the record, followed by the
+contents of the record. The details of this are left to section on abbreviations
+[ref]. However, at the record level, one important aspect of this appears in
+block enter records.  These records must define how many bits are required to
+hold abbreviation indices associated with records of that block.</p>
+<p>There are 4 predefined (default) abbreviation indices, used as the default
+abbreviations for PNaCl records. They are:</p>
+<dl class="docutils">
+<dt>0</dt>
+<dd>Abbreviation index for the abbreviation used to bit-encode an exit block
+record.</dd>
+<dt>1</dt>
+<dd>Abbreviation index for the abbreviation used to bit-encode a enter block
+record.</dd>
+<dt>2</dt>
+<dd>Abbreviation index for the abbreviation used to bit-encode a user-defined
+abbreviation record.</dd>
+<dt>3</dt>
+<dd>Abbreviation index for the default abbreviation to bit-encode all other
+records in the bitcode file.</dd>
+</dl>
+<p>A block may (in addition), define a list of block specific, user-defined,
+abbreviations (of length <em>U</em>). The number of bits <em>B</em> specified for an enter
+record must be sufficiently large such that</p>
+<pre class="prettyprint">
+2**B &gt;= U + 4
+</pre>
+<p>In addition, the upper limit for B is 32.</p>
+<p>PNaClAsm requires that you specify the number of bits needed to read
+abbreviations as part of the enter block record. This allows the PNaCl bitcode
+reader/writer to use the specified number of bits to encode abbreviation
+indices.</p>
+</section><section id="conventions-for-describing-records">
+<h2 id="conventions-for-describing-records">Conventions for describing records</h2>
+<p>PNaClAsm is the textual representation of PNaCl records.  Each PNaCl record is
+described by a corresponding PNaClAsm construct. These constructs are described
+using syntax rules, and semantics on how they are converted to records. The
+parser also has state, that is updated after the record is processed.  These
+state updates are part of the semantics of the corresponding record construct.</p>
+<p>For each PNaCl construct, we define multiple subsections. The <strong>Syntax</strong>
+subsection defines a syntax rule for the construct. The <strong>Record</strong> subsection
+defines the corresponding record associated with the syntax rule. The
+<strong>Semantics</strong> subsection describes the semantics associated with the record, in
+terms of data within the parse state and the corresponding syntax.</p>
+<p>The <strong>Constraints</strong> subsection (if present) defines any constraints associated
+with the construct. The <strong>Updates</strong> subsection (if present) defines how the
+parse state is updated when the construct is parsed.  The <strong>Examples</strong>
+subsection gives one (or more) examples of using the corresponding PNaClAsm
+construct.</p>
+<p>Some semantics subsections use functions to compute values. The meaning of
+functions can be found in <em>Support Functions</em> [ref].</p>
+<p>Within a syntax rule, there may specifications about abbreviations.  These
+abbreviation specifications, if allowed, are at the end of the construct, and
+enclosed in <em>&lt;</em> and <em>&gt;</em> brackets. These abbreviation specifications are optional
+in the syntax, and can be omitted. If they are used, the abbreviation brackets
+are part of the actual syntax of the construct. To make it clear that
+abbreviation specifications are optional, syntax rules separate abbreviation
+specifications using plenty of whitespace.</p>
+<p>Abbreviation specifications consist of user-defined abbreviations, abbreviation
+identifiers, and the number of bits required to represent abbreviations in a
+block. These notations appear, as appropriate, in the corresponding syntax
+rules.</p>
+<p>The most common abbreviation syntax is the corresponding abbreviation identifier
+to use to read/write the corresponding record. In such cases, if the specified
+abbreviation identifier is omitted, the corresponding default abbreviation will
+be used by the PNaCl reader/writer.</p>
+<p>Also, within the syntax rule, all alphabetic characters are lower case unless
+they appear within a literal value. Hence, if we mix lower and upper case
+letters within a name appearing in a syntax rule, the lower case letters are
+literal while the upper case sequence of letters denote (rule specific)
+values. If an upper case sequence of letters is followed by digits, the
+corresponding embedded name includes both the upper case letters and the digits.
+The valid values for each of these names will be defined in the corresponding
+semantics subsection.</p>
+<p>For example, consider the following syntax rule:</p>
+<pre class="prettyprint">
+%vN = add T O1, O2;                            &lt;A&gt;
+</pre>
+<p>This rule defines a PNaClAsm add instruction.  This construct defines an
+instruction that adds to two values (<em>O1</em> and <em>O2</em>) to generate instruction
+value <em>%vN</em>. The types of the arguments, and the result, are all of type
+<em>T</em>. Since abbreviation ID <em>A</em> is present, the record is encoded using that
+abbreviation.</p>
+<p>To be concrete, the syntactic rule above defines the structure of the following
+PNaClAsm examples.</p>
+<pre class="prettyprint">
+%v10 = add i32 %v1, %v2;  &lt;&#64;a5&gt;
+%v11 = add i32 %v10, %v3;
+</pre>
+<p>In addition to specifying the syntax, each syntax rule also specifies the
+contents of the corresponding record in the corresponding record subsection. In
+simple cases, the elements of the corresponding record are predefined (literal)
+constants. Otherwise the record element is a name that is defined by the other
+subsections associated with the construct.</p>
+</section><section id="factorial-example">
+<h2 id="factorial-example">Factorial Example</h2>
+<p>This section provides a simple example of a PNaCl bticode file. Its contents
+describes a bitcode file that only defines a function to compute the factorial
+value of a number.</p>
+<p>In C, the factorial function can be defined as:</p>
+<pre class="prettyprint">
+int fact(int n) {
+  if (n == 0) return 1;
+  return n * fact(n-1);
+}
+</pre>
+<p>Compiling this into a PEXE file, and dumping out its contents with utility
+<em>pnacl-bcdis</em>, the corresponding output is:</p>
+<pre class="prettyprint">
+  0:0|&lt;65532, 80, 69, 88, 69, 1, 0,|Magic Number: 'PEXE' (80, 69, 88, 69)
+     | 8, 0, 17, 0, 4, 0, 2, 0, 0, |PNaCl Version: 2
+     | 0&gt;                          |
+ 16:0|1: &lt;65535, 8, 3&gt;             |module {  // BlockID = 8
+ 24:0|  3: &lt;1, 1&gt;                  |  version 1;
+ 26:5|  1: &lt;65535, 0, 2&gt;           |  abbreviations {  // BlockID = 0
+ 36:0|  0: &lt;65534&gt;                 |  }
+ 40:0|  1: &lt;65535, 17, 4&gt;          |  types {  // BlockID = 17
+ 48:0|    3: &lt;1, 4&gt;                |    count 4;
+ 50:6|    3: &lt;7, 32&gt;               |    &#64;t0 = i32;
+ 54:2|    3: &lt;2&gt;                   |    &#64;t1 = void;
+ 56:2|    3: &lt;21, 0, 0, 0&gt;         |    &#64;t2 = i32 (i32);
+ 60:4|    3: &lt;7, 1&gt;                |    &#64;t3 = i1;
+ 63:2|  0: &lt;65534&gt;                 |  }
+ 64:0|  3: &lt;8, 2, 0, 0, 0&gt;         |  define external i32 &#64;f0(i32);
+ 68:7|  1: &lt;65535, 19, 4&gt;          |  globals {  // BlockID = 19
+ 76:0|    3: &lt;5, 0&gt;                |    count 0;
+ 78:6|  0: &lt;65534&gt;                 |  }
+ 80:0|  1: &lt;65535, 14, 4&gt;          |  valuesymtab {  // BlockID = 14
+ 88:0|    3: &lt;1, 0, 102, 97, 99,   |    &#64;f0 : &quot;fact&quot;;
+     |        116&gt;                 |
+ 96:6|  0: &lt;65534&gt;                 |  }
+100:0|  1: &lt;65535, 12, 5&gt;          |  function i32 &#64;f0(i32 %p0) {
+     |                             |                   // BlockID = 12
+108:0|    3: &lt;1, 3&gt;                |    blocks 3;
+110:7|    1: &lt;65535, 11, 4&gt;        |    constants {  // BlockID = 11
+120:0|      3: &lt;1, 0&gt;              |      i32:
+122:6|      3: &lt;4, 2&gt;              |        %c0 = i32 1;
+125:4|      3: &lt;4, 0&gt;              |        %c1 = i32 0;
+128:2|    0: &lt;65534&gt;               |      }
+     |                             |  %b0:
+132:0|    3: &lt;28, 1, 2, 32&gt;        |    %v0 = icmp eq i32 %c1, %c0;
+137:1|    3: &lt;11, 1, 2, 1&gt;         |    br i1 %v0, %b1, %b2;
+     |                             |  %b1:
+141:4|    3: &lt;10, 3&gt;               |    ret i32 %c0;
+     |                             |  %b2:
+144:3|    3: &lt;2, 4, 3, 1&gt;          |    %v1 = sub i32 %p0, %c0;
+148:6|    3: &lt;34, 0, 6, 1&gt;         |    %v2 = call i32 &#64;f0(i32 %p0);
+153:7|    3: &lt;2, 6, 1, 2&gt;          |    %v2 = mul i32 &#64;f0, %v1;
+158:2|    3: &lt;10, 1&gt;               |    ret i32 %v2;
+161:1|  0: &lt;65534&gt;                 |  }
+164:0|0: &lt;65534&gt;                   |}
+</pre>
+<p>Note that there are three columns in this output. The first column contains the
+bit positions of the records within the bitcode file. The second column contains
+the sequence of records within the bitcode file. The third column contains the
+corresponding PNaClAsm program.</p>
+<p>Bit positions are defined by a pair <em>B:N</em>. <em>B</em> is the number of bytes, while <em>N</em>
+is the bit offset within the <em>B+1</em> byte. Hence, the bit position (in bits) is:</p>
+<pre class="prettyprint">
+B*8 + N
+</pre>
+<p>Hence, the first <em>header</em> record is at bit offset 0 (0*8+0). The second record
+is at bit offset 128 (16*8+0).  The third record is at bit offset 192 (24*8+0).
+The fourth record is at bit offset 213 (26*8+5).</p>
+<p>The header record is a sequence of 16 bytes, defining the contents of the first
+16 bytes of the bitcode file. The first four bytes define the magic number of
+the file. That is, &#8216;PEXE&#8217;. All PEXE bitcode files begin with these four bytes.
+Byte 13 defines the PNaCl bitcode version of the file. Currently, only version 2
+is allowed.</p>
+<p>All but the header record has an abbreviation index associated with it. Since no
+user-defined abbreviations are provided, all records use the default
+abbreviation.</p>
+<p>The types block (starting at bit address 40:0), defines 4 types: <em>i1</em>, <em>i32</em>,
+<em>void</em>, and function signature <em>i32(i32)</em>.</p>
+<p>Bit address 64:0 declares the factorial function address &#64;f0, and its
+corresponding type signature. Bit address 88:0 associates the name &#8220;fact&#8221; with
+function address &#64;f0.</p>
+<p>Bit address 100:0 defines the function block that implemnts function &#8220;fact&#8221;. The
+entry point is %b0 (at bit address 132:0). It uses the 32-bit integer constants
+1 and 0 (defined at bit addresses 122:6 and 125:4). Bit address 132:0 defines an
+equality comparison of the argument %p0 with 0 (constant %c1). Bit address 137:1
+defines a conditional branch. If the result of the previous comparison (%v0) is true,
+the program will branch to block %b1. Otherwise it will branch to block %b2.</p>
+<p>Bit address 141:4 returns constant 1 (%c0) when the input parameter is 0.
+Instructions between bit address 144:3 and 158:2 compute and return &#8220;n *
+fact(n-1)&#8221;.</p>
+</section><section id="parse-state">
+<h2 id="parse-state">Parse State</h2>
+<p>This section describes the parse state of the PNaClAsm assembler. It is used to
+define contextual data that is carried between records. The following
+subsections describe each element of the parse state.</p>
+<section id="typing">
+<h3 id="typing">Typing</h3>
+<p>Associated with most identifiers is a type. This type defines what type the
+corresponding value has. It is defined by the (initially empty) map</p>
+<pre class="prettyprint">
+TypeOf: ID -&gt; Type
+</pre>
+<p>For each type in the <em>types block</em> [ref], a corresponding inverse map</p>
+<pre class="prettyprint">
+TypeID: Type -&gt; ID
+</pre>
+<p>is maintained to convert syntactic types to the corresponding type ID.</p>
+<p>Note: This document assumes that map <em>TypeID</em> is automatically maintained during
+updates to map <em>TypeOf</em> (when given a type ID). Hence, <em>updates</em> subsections
+will not contain assignments to this map.</p>
+<p>Associated with each function identifier is its type signature. This is
+different than the type of the function identifier, since function identifiers
+are pointers (and always implemented as a 32-bit integer).</p>
+<p>Function type signatures are maintained using:</p>
+<pre class="prettyprint">
+TypeOfFcn: ID -&gt; Type
+</pre>
+<p>In addition, if a function address has an implementing block, there is a
+corresponding implementation associated with the function address. To capture
+this association, we use the set:</p>
+<pre class="prettyprint">
+DefiningFcnIDs: set(ID)
+</pre>
+</section><section id="id-counters">
+<h3 id="id-counters">ID Counters</h3>
+<p>Each block defines one (or more) kinds of values.  Value indices are generated
+sequentially, starting at zero. To capture this, the following counters are
+defined:</p>
+<dl class="docutils">
+<dt>NumTypes</dt>
+<dd>The number of types defined so far (in the types block)</dd>
+<dt>NumFuncAddresses</dt>
+<dd>The number of function addresses defined so far (in the module block).</dd>
+<dt>NumDefinedFcnAddresses</dt>
+<dd>The number of defining function addresses defined so far (in the module
+block).</dd>
+<dt>NumFuncImpls</dt>
+<dd>The number of implemented functions defined so far (in the module block).</dd>
+<dt>NumGlobalAddresses</dt>
+<dd>The number of global variable/constant addresses defined so far (in the
+globals block).</dd>
+<dt>NumParams</dt>
+<dd>The number of parameters defined for a function.</dd>
+<dt>NumFcnConsts</dt>
+<dd>The number of constants defined in a function.</dd>
+<dt>NumBasicBlocks</dt>
+<dd>The number of basic blocks defined so far (within a function block).</dd>
+<dt>NumValuedInsts</dt>
+<dd>The number of instructions, generating values, defined so far (within a
+function block).</dd>
+</dl>
+</section><section id="size-variables">
+<h3 id="size-variables">Size Variables</h3>
+<p>A number of blocks define expected sizes of constructs. These sizes are recorded
+in the following size variables:</p>
+<dl class="docutils">
+<dt>ExpectedBasicBlocks</dt>
+<dd>The expected number of basic blocks within a function implementation.</dd>
+<dt>ExpectTypes</dt>
+<dd>The expected number of types defined in the types block.</dd>
+<dt>ExpectedGlobals</dt>
+<dd>The expected number of global variable/constant addresses in the globals
+block.</dd>
+<dt>ExpectedInitializers</dt>
+<dd>The expected number of initializers for a global variable/constant address in
+the globals block.</dd>
+</dl>
+</section><section id="other-variables">
+<h3 id="other-variables">Other Variables</h3>
+<dl class="docutils">
+<dt>EnclosingFcnID</dt>
+<dd>The function ID of the function block being processed.</dd>
+</dl>
+</section></section><section id="special-records">
+<h2 id="special-records">Special records</h2>
+<p>There are four special PNaCl records, each having its own record code. These
+special records are:</p>
+<dl class="docutils">
+<dt>Header</dt>
+<dd>The header record is the first record of a PNaCl bitcode file, and identifies
+the file&#8217;s magic number, as well as the bitcode version it uses. The record
+defines the sequence of bytes that make up the header and uniquely identifies
+the file as a PNaCl bitcode file.</dd>
+<dt>Enter</dt>
+<dd>An enter record defines the beginning of a block. Since blocks can be nested,
+one can appear inside other blocks, as well as at the top level.</dd>
+<dt>Exit</dt>
+<dd>An exit record defines the end of a block. Hence, it must appear in every
+block, to end the block.</dd>
+<dt>Abbreviation</dt>
+<dd>An abbreviation record defines a user-defined abbreviation to be applied to
+records within blocks.  Abbreviation records appearing in the abbreviations
+block define global abbreviations. All other abbreviations are local to the
+block they appear in, and can only be used in that block.</dd>
+</dl>
+<p>All special records can&#8217;t have user-defined abbreviations associated with
+them. The default abbreviation is always used.</p>
+<p>The following subsections define valid special records, other than abbreviation
+records. Abbreviation records are described in the Abbreviations [ref] section.</p>
+<section id="header-record">
+<h3 id="header-record">Header Record</h3>
+<p>The header record must be the first record in the file. It is the only record in
+the bitcode file that doesn&#8217;t have a corresponding construct in
+PNaClAsm.</p>
+<p><strong>Syntax</strong></p>
+<p>There is no syntax for header records in PNaClAsm. It is automatically inserted
+by the PNaCl bitcode writer.</p>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+&lt;65532, 80, 69, 88, 69, 1, 0, 8, 0, 17, 0, 4, 0, 2, 0, 0, 0&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The header record defines the initial sequence of bytes that must appear at the
+beginning of all (PNaCl bitcode version 2) files. That sequence is the list of
+bytes inside the record (excluding the record code). As such, it uniquely
+identifies PNaCl bitcode files.</p>
+<p><strong>Examples</strong></p>
+<p>There are no examples for the header record, since it is not part of PNaClAsm.</p>
+</section><section id="enter-block-record">
+<h3 id="enter-block-record">Enter Block Record</h3>
+<p>Block records can be top-level, as well as nested in other blocks. Blocks must
+begin with an <em>enter</em> record, and end with an <em>exit</em> record.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+N {                                             &lt;B&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+1: &lt;65535, ID, B&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>Enter block records define the beginning of a block.  <em>B</em>, if present, is the
+number of bits needed to represent all possible abbreviation indices used within
+the block. If omitted, B=2 is assumed.</p>
+<p>The block <em>ID</em> value is dependent on the name <em>N</em>. Valid names and corresponding
+<em>BlockID</em> values are defined as follows:</p>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">N</th>
+<th class="head">Block ID</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>abbreviations</td>
+<td>0</td>
+</tr>
+<tr class="row-odd"><td>constants</td>
+<td>11</td>
+</tr>
+<tr class="row-even"><td>function</td>
+<td>12</td>
+</tr>
+<tr class="row-odd"><td>globals</td>
+<td>19</td>
+</tr>
+<tr class="row-even"><td>module</td>
+<td>8</td>
+</tr>
+<tr class="row-odd"><td>types</td>
+<td>17</td>
+</tr>
+<tr class="row-even"><td>valuesymtab</td>
+<td>14</td>
+</tr>
+</tbody>
+</table>
+<p>Note: For readability, PNaClAsm allows a more readable form of a function block
+enter record.  See <em>function blocks</em> [ref] for more details.</p>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+module {
+  types {
+    count: 0;
+  }
+  globals {
+    count: 0;
+  }
+}
+</pre>
+<p>This example defines a module, types, and globals block. Both the type and the
+globals block appear within the module block.</p>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 8, 2&gt;
+1: &lt;65535, 17, 2&gt;
+3: &lt;1, 0&gt;
+0: &lt;65534&gt;
+1: &lt;65535, 19, 2&gt;
+3: &lt;5, 0&gt;
+0: &lt;65534&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="exit-block-record">
+<h3 id="exit-block-record">Exit Block Record</h3>
+<p>Block records can be top-level, as well as nested, records. Blocks must begin
+with an <em>enter</em> record, and end with an <em>exit</em> record.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+}
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+0: &lt;65534&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>All exit records are identical, no matter what block they are ending. An exit
+record defines the end of the block.</p>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+module {
+  types {
+    count: 0;
+  }
+  globals {
+    count: 0;
+  }
+}
+</pre>
+<p>This example defines a module, types, and globals block. Both the type and the
+globals block appear within the module block.</p>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 8, 2&gt;
+1: &lt;65535, 17, 2&gt;
+3: &lt;1, 0&gt;
+0: &lt;65534&gt;
+1: &lt;65535, 19, 2&gt;
+3: &lt;5, 0&gt;
+0: &lt;65534&gt;
+0: &lt;65534&gt;
+</pre>
+</section></section><section id="types-block">
+<h2 id="types-block">Types Block</h2>
+<p>The types block defines all types used in a program. It must appear in the
+module block, before any function address records, the globals block, the
+valuesymtab block, and any function blocks.</p>
+<p>Each record in the types block defines a type used by the program.  Types can be
+broken into the following groups:</p>
+<dl class="docutils">
+<dt>Primitive Value types</dt>
+<dd>Defines the set of base types for values. This includes various sizes of
+integral and floating types.</dd>
+<dt>Void type</dt>
+<dd>A primitive type that doesn&#8217;t represent any value and has no size.</dd>
+<dt>Function types</dt>
+<dd>The type signatures of functions.</dd>
+<dt>Vector type</dt>
+<dd>Defines vectors of primitive types.</dd>
+</dl>
+<p>In addition, any type that is not defined using another type is a primitive
+type.  All other types (i.e. function and vector) are composite types.</p>
+<p>Types must be defined in a topological order, causing primitive types to appear
+before the composite types that use them. Each type must be unique. There are no
+additional restrictions on the order that types can be defined in a types block.</p>
+<p>The following subsections introduce each valid PNaClAsm type, and the
+corresponding PNaClAsm construct that defines the type. Types not defined in the
+types block, can&#8217;t be used in a PNaCl program.</p>
+<p>The first record of a types block must be a <em>count</em> record, defining how many
+types are defined by the types block. All remaining records defines a type. The
+following subsections define valid records within a types block. The order of
+type records is important. The position of each defining record implicitly
+defines the type ID that will be used to denote that type, within other PNaCl
+records of the bitcode file.</p>
+<p>To make this more concrete, consider the following example types block:</p>
+<pre class="prettyprint">
+types {
+  count: 4;
+  &#64;t0 = void;
+  &#64;t1 = i32;
+  &#64;t2 = float;
+  &#64;t3 = void (i32, float);
+}
+</pre>
+<p>This example defines a types block that defines four type IDs:</p>
+<ol class="arabic simple" start="0">
+<li>The void type.</li>
+<li>A 32-bit integer type.</li>
+<li>A 32-bit floating type.</li>
+<li>A function, taking 32-bit integer and float arguments that returns void.</li>
+</ol>
+<p>Note that the order defines the corresponding identifier that will be used for
+that type, and is based on the position of the type within the types
+record. Hence, the assignment to identifier <em>&#64;tN</em> can never appear before the
+assignment to identifier <em>&#64;tN-1</em>. Further, if type identifier <em>&#64;tN</em> is assigned,
+it must appear immediately after the assignment to identifier <em>&#64;tN-1</em>.</p>
+<section id="count-record">
+<h3 id="count-record">Count Record</h3>
+<p>The <em>count record</em> defines how many types are defined in the types
+block. Following the types count record are records that define types used by
+the PNaCl program.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+count: N;                                       &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<blockquote>
+<div>AA: &lt;1, N&gt;</div></blockquote>
+<p><strong>Semantics</strong></p>
+<p>This construct defines the number of types used by the PNaCl program.  <em>N</em> is
+the number of types defined in the types block. It is an error to define more
+(or fewer) types than value <em>N</em>, within the enclosing types block. <em>A</em> is the
+(optional) abbreviation associated with the record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+0 == NumTypes
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+ExpectedTypes = N;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+types {
+  count: 2;
+  &#64;t0 = float;
+  &#64;t1 = i32;
+}
+</pre>
+<p>This example defines two types.  A 32 bit integer and a 32 bit floating types.
+The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 17, 2&gt;
+3: &lt;1, 2&gt;
+3: &lt;3&gt;
+3: &lt;7, 32&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="void-type">
+<h3 id="void-type">Void Type</h3>
+<p>The <em>void</em> type record defines the void type, which corresponds to the type that
+doesn&#8217;t define any value, and has no size.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+&#64;tN = void;                                     &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The void type record defines the type that has no values and has no size.  <em>A</em>
+is the (optional) abbreviation associated with the record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+N == NumTypes
+NumTypes &lt; ExpectedTypes
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumTypes;
+TypeOf(&#64;tN) = void;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+&#64;t0 = void;
+</pre>
+<p>defines the record</p>
+<pre class="prettyprint">
+3: &lt;2&gt;
+</pre>
+</section><section id="integer-types">
+<h3 id="integer-types">Integer Types</h3>
+<p>PNaClAsm allows integral types for various bit sizes. Valid bit sizes are 1, 8,
+16, 32, and 64. Integers can be signed or unsigned, but the signed component of
+an integer is not specified by the type. Rather, individual instructions
+determine whether the value is assumed to be signed or unsigned.</p>
+<p>It should be noted that in PNaClAsm, all pointers are implemented as 32-bit
+(unsigned) integers.  There isn&#8217;t a separate type for pointers. The only way to
+tell that a 32-bit integer is a pointer, is when it is used in an instruction
+that requires a pointer (such as load and store instructions).</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+&#64;tN = iB;                                      &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<blockquote>
+<div>AA: &lt;7, B&gt;</div></blockquote>
+<p><strong>Semantics</strong></p>
+<p>An integer type record defines an integral type. <em>B</em> defines the number of bits
+of the integral type.  <em>A</em> is the (optional) abbreviation associated with the
+record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+N == NumTypes
+NumTypes &lt; ExpectedTypes
+B in {1, 8, 16, 32, 64}
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumTypes;
+TypeOf(&#64;tN) = iB;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+&#64;t1 = i32;
+&#64;t2 = i1;
+&#64;t3 = i64;
+</pre>
+<p>defines the records</p>
+<pre class="prettyprint">
+3: &lt;7, 32&gt;
+3: &lt;7, 1&gt;
+3: &lt;7, 64&gt;
+</pre>
+</section><section id="bit-floating-type">
+<h3 id="bit-floating-type">32-Bit Floating Type</h3>
+<p>PNaClAsm allows computation on 32-bit floating values. A floating type record
+defines the 32-bit floating type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+&#64;tN = float;                                    &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;3&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>A floating type record defines the 32-bit floating type.  <em>A</em> is the (optional)
+abbreviation associated with the record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A).
+N == NumTypes
+NumTypes &lt; ExpectedTypes
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumTypes;
+TypeOf(&#64;tN) = float;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+&#64;t5 = float;
+</pre>
+<p>defines the record</p>
+<pre class="prettyprint">
+3: &lt;3&gt;
+</pre>
+</section><section id="id1">
+<h3 id="id1">64-bit Floating Type</h3>
+<p>PNaClAsm allows computation on 64-bit floating values. A double type record
+defines the 64-bit floating type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+&#64;tN = double;                                   &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;4&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>A double type record defines the 64-bit floating type.  <em>A</em> is the (optional)
+abbreviation associated with the record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+N == NumTypes
+NumTypes &lt; ExpectedTypes
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumTypes;
+TypeOf(&#64;tN) = double;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+&#64;t3 = double;
+</pre>
+<p>defines the record</p>
+<pre class="prettyprint">
+3: &lt;4&gt;
+</pre>
+</section><section id="vector-types">
+<h3 id="vector-types">Vector Types</h3>
+<p>TODO(kschimpf) &lt;N x T&gt;</p>
+<p>TODO(kschimpf) Define integral and floating vector types.</p>
+</section><section id="function-type">
+<h3 id="function-type">Function Type</h3>
+<p>The <em>function</em> type can be thought of as a function signature. It consists of a
+return type, and a (possibly empty) list of formal parameter types.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%tN = RT (T1, ... , TM)                         &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;21, 0, IRT, IT1, ... , ITM&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The function type defines the signature of a function. <em>RT</em> is the return type
+of the function, while types <em>T1</em> through <em>TM</em> are the types of the
+arguments. Indicies to the corresponding type identifiers is stored in the
+corresponding record.</p>
+<p>The return value must either be a primitive type, type <em>void</em>, or a vector type.
+Parameter types can be a primitive or vector type.</p>
+<p>For the integral types, only i32 and i64 can be used for a return or parameter
+type. All other integral types are not allowed.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+M &gt;= 0
+IRT = AbsoluteIndex(TypeID(RT))
+IT1 = AbsoluteIndex(TypeID(T1))
+...
+ITM = AbsoluteIndex(TypeID(TM))
+N == NumTypes
+NumTypes &lt; ExpectedTypes
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumTypes;
+TypeOf(&#64;tN) = RT (T1, ... , TM)
+</pre>
+<p><strong>Examples</strong></p>
+<p>The following example defines two function signatures (<em>&#64;t4</em> and <em>&#64;t5</em>):</p>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 17, 2&gt;
+3: &lt;1, 6&gt;
+3: &lt;7, 32&gt;
+3: &lt;7, 64&gt;
+3: &lt;3&gt;
+3: &lt;2&gt;
+3: &lt;21, 3, 0, 2, 1&gt;
+3: &lt;21, 0&gt;
+0: &lt;65534&gt;
+</pre>
+</section></section><section id="globals-block">
+<h2 id="globals-block">Globals block</h2>
+<p>The globals block defines global addresses of variables and constants, used by
+the PNaCl program. It also defines the memory associated with the global
+addresses, and how to initialize each global variable/constant. It must appear
+in the module block. It must appear after the types block, as well as after all
+function address records. But, it must also appear before the valuesymtab block,
+and any function blocks.</p>
+<p>The globals block begins with a count record, defining how many global addresses
+are defined by the PNaCl program. It is then followed by a sequence of records
+that defines how each global address is initialized.</p>
+<p>The standard sequence, for defining global addresses, begins with a global
+address record.  It is then followed by a sequence of records defining how the
+global address is initialized.  If the initializer is simple, a single record is
+used. Otherwise, the initializer is preceded with a compound record, specifying
+a number <em>N</em>, followed by sequence of <em>N</em> simple initializer records.</p>
+<p>The size of the memory referenced by each global address is defined by its
+initializer records. All simple initializer records define a sequence of
+bytes. A compound initializer defines the sequence of bytes by concatenating the
+corresponding sequence of bytes for each of its simple initializer records.</p>
+<p>For notational convenience, PNaClAsm begins a compound record with a &#8220;{&#8221;, and
+inserts a &#8220;}&#8221; after the last initializer record associated compound record. This
+latter &#8220;}&#8221; does not correspond to any record. It is implicitly assumed by the
+size specified in the compound record, and is added only to improve readability.</p>
+<p>Explicit alignment is specified for global addresses, and must be a power
+of 2. If the alignment is 0, the alignment of the global is set by the target to
+whatever it feels convenient. If the value is greater than zero, the global is
+forced to have exactly that alignment.</p>
+<p>For example, consider the following:</p>
+<pre class="prettyprint">
+globals {
+  count: 2;
+  const &#64;g0 =
+    zerofill 8;
+  var &#64;g1 =
+    initializers 2 {
+      {1, 2, 3, 4},
+      zerofill 2;
+    }
+}
+</pre>
+<p>TODO: Rewrite this: Base example by line number and corresponding record.</p>
+<p>In this example, the globals block contains 9 records. All lines, inside the
+block delimiters of this example (except the second to last) defines a
+record. The first record, &#8220;globals {&#8221;, is the beginning of the globals block.
+The second record, &#8220;count: 2;&#8221;, defines the number of global addresses defined
+by the program, i.e. 2.</p>
+<p>The third record, &#8220;const &#64;g0 = &#8221;, defines the global constant address <em>&#64;g0</em>.
+The forth record, &#8220;zerofill 8;&#8221;, defines to initialize the constant with 8
+bytes, all with the value zero. Thus, the size of <em>&#64;g0</em> is 8 bytes.</p>
+<p>The fifth record, &#8220;var &#64;g1 =&#8221;, defines the global variable address <em>&#64;g1</em>. The
+sixth record, &#8220;initializers 2 ..&#8221;, defines that the initial value of <em>&#64;g1</em> is
+defined by the sequence of bytes defined by the following 2 initializer
+records. The seventh record, &#8220;{1, 2, 3, 4}, defines that the first 4 bytes of
+<em>&#64;g1</em> are initialized with bytes 1, 2, 3, 4. The eighth record, &#8220;zerofill 2&#8221;;
+initializes bytes 5 and 6 to zero. The size of <em>&#64;g1</em> is therefore 6 bytes.</p>
+<p>The nine record is the exit block record.</p>
+<p>In other words, the corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 19, 2&gt;
+3: &lt;5, 2&gt;
+3: &lt;0, 0, 1&gt;
+3: &lt;2, 8&gt;
+3: &lt;0, 0, 0&gt;
+3: &lt;1, 2&gt;
+3: &lt;3, 1, 2, 3, 4&gt;
+3: &lt;2, 2&gt;
+0: &lt;65534&gt;
+</pre>
+<section id="id2">
+<h3 id="id2">Count Record</h3>
+<p>The count record defines the number of global addresses used by the PNaCl
+program.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+count: N;                                       &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;5, N&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>This record must appear first in the globals block.  The count record defines
+the number of global addresses used by the program. <em>A</em> is the (optional)
+abbreviation associated with the record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+ExpectedGlobals = N;
+ExpectedInitializers = 0;
+</pre>
+</section><section id="global-variable-addressses">
+<h3 id="global-variable-addressses">Global Variable Addressses</h3>
+<p>A global variable address record defines a global address to global data.  The
+global variable address record must be immediatedly followed by initializer
+record(s) that define how the corresponding global variable is initialized.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+var &#64;gN, align V =                              &lt;A&gt;
+var &#64;gN =                                       &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;0, VV, 0&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>A global varaible address record defines a global address for a global variable.
+<em>V</em> is the alignment to for the global variable. <em>VVA</em> is the corresponding
+number of bits associated with alignment <em>V</em> (see <em>constraints</em>).  The alignment
+<em>V</em> clause can be omitted if <em>V</em> is zero. <em>A</em> is the (optional) abbreviation
+associated with the record.</p>
+<p>It is assumed that the memory, referenced by the global variable address, can be
+both read and written to.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+N = NumGlobalAddresses
+NumGlobalAddresses &lt; ExpectedGlobals
+ExpectedInitializers = 0
+VV = Log2(V+1)
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumGlobalAddresses;
+ExpectedInitializers = 1;
+TypeOf(&#64;gN) = i32;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+var &#64;g0 =
+  zerofill 8;
+var &#64;g1 =
+  {1, 2, 3, 4}
+</pre>
+<p>This example defines two global variable addresses, <em>&#64;g0</em> and <em>&#64;g1</em>. Both use
+memory alignment of 0. <em>&#64;g0</em> is an 8 byte variable initialized to zero.  <em>&#64;g1</em>
+is a 4 byte variable, initialized by the sequence of bytes 1, 2, 3, and 4.</p>
+<p>The corresponding records defined by the example above are:</p>
+<pre class="prettyprint">
+3: &lt;0, 0, 0&gt;
+3: &lt;2, 8&gt;
+3: &lt;0, 0, 0&gt;
+3: &lt;3, 1, 2, 3, 4&gt;
+</pre>
+</section><section id="global-constant-addresses">
+<h3 id="global-constant-addresses">Global Constant Addresses</h3>
+<p>A global constant address record defines an address corresponding to a global
+constant that can&#8217;t be modified by the program. The global constant address
+record must be immediatedly followed by initializer record(s) that define how
+the corresponding global constant is initialized.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+const &#64;gN, align V =                            &lt;A&gt;
+const &#64;gN =                                     &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;0, VV, 1&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>A global constant address record defines a global address for a global constant.
+<em>V</em> is the memory alignment for the global constant. <em>VV</em> is the corresponding
+number of bits associated with alignment <em>V</em> (see <em>constraints</em>).  The alignment
+<em>V</em> caluse can be omitted if <em>V</em> is zero. <em>A</em> is the (optional) abbreviation
+associated with the record.</p>
+<p>It is assumed that the memory, referenced by the global constant
+address, is only read, and can&#8217;t be written to.</p>
+<p>Note that the only difference between a global variable address and a global
+constant address record is the third element of the record. If the value is
+zero, it defines a global variable address. If the value is one, it defines a
+global constant address.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+N = NumGlobalAddresses
+NumGlobalAddresses &lt; ExpectedGlobals
+ExpectedInitializers = 0
+VV = Log2(V+1)
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumGlobalAddresses;
+ExpectedInitializers = 1;
+TypeOf(&#64;gN) = i32;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+const &#64;g0 =
+  zerofill 8;
+var &#64;g1 =
+  {1, 2}
+</pre>
+<p>This example defines two global constants, with global addresses <em>&#64;g0</em> and
+<em>&#64;g1</em>. <em>&#64;g0</em> is an 8 byte constant initialized to zero.  <em>&#64;g1</em> is a 2 byte
+variable, initialized by the sequence of bytes 1 and 2.</p>
+<p>The corresponding PNaCl bitcode records are:</p>
+<pre class="prettyprint">
+3: &lt;0, 0, 1&gt;
+3: &lt;2, 8&gt;
+3: &lt;0, 0, 1&gt;
+3: &lt;3, 1, 2&gt;
+</pre>
+</section><section id="zerofill-initializer">
+<h3 id="zerofill-initializer">Zerofill Initializer</h3>
+<p>The zerofill initializer record intializes a sequence of bytes, associated with
+a global address, with zeros.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+zerofill N;                                     &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, N&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>A zerofill initializer record intializes a sequence of bytes, associated with a
+global address, with zeros. <em>A</em> is the (optional) abbreviation of the associated
+record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+ExpectedInitializers &gt; 0;
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+--ExpectedInitializers;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+const &#64;g0 =
+  zerofill 8;
+var &#64;g1 =
+  zerofill 4;
+</pre>
+<p>This example defines two global constants, with global addresses <em>&#64;g0</em> and
+<em>&#64;g1</em>.  The global memory associated with address <em>&#64;g0</em>, is an eight byte value,
+initialized to zero.  The global memory associated with address <em>&#64;g1</em>, is a 4
+byte value, initialized to zero.</p>
+<p>The corresponding PNaCl records are:</p>
+<pre class="prettyprint">
+3: &lt;0, 0, 1&gt;
+3: &lt;2, 8&gt;
+3: &lt;0, 0, 1&gt;
+3: &lt;2, 4&gt;
+</pre>
+</section><section id="data-initializer">
+<h3 id="data-initializer">Data Initializer</h3>
+<p>Data records define a sequence of bytes. These bytes define the initial value of
+the contents of the corresponding memory.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+{ B1 , .... , BN }                              &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;3, B1, ..., BN&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>A data record defines a sequence of bytes <em>B1</em> throught <em>BN</em>, that intialize <em>N</em>
+bytes of memory. <em>A</em> is the (optional) abbreviation associated with the
+record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+ExpectedInitializers &gt; 0
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+--ExpectedInitializers;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+const &#64;g0 =
+  {1, 2, 97, 36, 44, 88, 44}
+const &#64;g1 =
+  initializers 3 {
+    {4, 5, 6, 7}
+    reloc &#64;f1;
+    {99, 66, 22, 12}
+  }
+</pre>
+<p>The corresponding PNaCl records are:</p>
+<pre class="prettyprint">
+3: &lt;0, 0, 1&gt;
+3: &lt;3, 1, 2, 97, 36, 44, 88, 44&gt;
+3: &lt;0, 0, 1&gt;
+3: &lt;1, 3&gt;
+3: &lt;3, 4, 5, 6, 7&gt;
+3: &lt;4, 1&gt;
+3: &lt;3, 99, 66, 22, 12&gt;
+</pre>
+</section><section id="relocation-initializer">
+<h3 id="relocation-initializer">Relocation Initializer</h3>
+<p>A relocation initializer record allows one to define the initial value of a
+global address with the value of another global address (i.e. either function,
+variable, or constant). Since addresses are pointers, a relocation initializer
+record defines 4 bytes of memory.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+reloc V;                                        &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;4, VV&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>A relocation initializer record defines a 4-byte value containing the specified
+global address <em>V</em>. <em>A</em> is the (optional) abbreviation associated with the
+record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+VV = AbsoluteIndex(V);
+ExpectedInitializers &gt; 0
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+--ExpectedInitializers;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+var &#64;g0 =
+  initializers 3 {
+    reloc &#64;f1;
+    reloc &#64;g0;
+    reloc &#64;g10;
+  }
+</pre>
+<p>This example defines global address <em>&#64;g0</em>. It defines 12 bytes of memory, and is
+initialized with three addresses <em>&#64;f1</em>, <em>&#64;g0</em>, and <em>&#64;g10</em>. Note that all globals
+can be used in a relocation initialization record, even if it isn&#8217;t defined yet.</p>
+<p>Assuming</p>
+<pre class="prettyprint">
+100 = AbsoluteIndex(&#64;g0))
+</pre>
+<p>The corresponding PNaCl bitcode records are:</p>
+<pre class="prettyprint">
+3: &lt;0, 0, 0&gt;
+3: &lt;1, 3&gt;
+3: &lt;4, 1&gt;
+3: &lt;4, 100&gt;
+3: &lt;4, 110&gt;
+</pre>
+</section><section id="subfield-relocation-initializer">
+<h3 id="subfield-relocation-initializer">Subfield Relocation Initializer</h3>
+<p>A subfield relocation initializer record allows one to define the initial value
+of a global address with the value of another (non-function) global address
+(i.e. either variable or constant), plus a constant. Since addresses are
+pointers, a relocation initializer record defines 4 bytes of memory.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+reloc V + O;                                    &lt;A&gt;
+reloc V - O;                                    &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;4, VV, OOO&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>A relocation initializer record defines a 4-byte value containing the specified
+global (non-funciton) address <em>V</em>, modified by the unsigned offset <em>O</em>. <em>OO</em> is
+the corresponding signed offset. In the first form, <em>OO == O</em>. In the second
+form, <em>OO == - O</em>.  <em>A</em> is the (optional) abbreviation associated with the
+record. <em>a</em> is the corresponding abbreviation index of <em>A</em>. When <em>A</em> is omitted,
+<em>a=3</em>.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+VV == AbsoluteIndex(V)
+ExpectedInitializers &gt; 0
+OOO == SignRotate(OO)
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+--ExpectedInitializers;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+var &#64;g0 =
+  initializers 3 {
+    reloc &#64;f1;
+    reloc &#64;g0 + 4;
+    reloc &#64;g10 - 3;
+  }
+</pre>
+<p>This example defines global address <em>&#64;g0</em>, and is initialized with three
+pointers, addresses <em>&#64;f1</em>, <em>&#64;g0+4</em>, and <em>&#64;g10-3</em>. Note that all global addresses
+can be used in a relocation initialization record, even if it isn&#8217;t defined
+yet. Validity of the reference can be verified, since a global address <em>&#64;g10</em>
+must be smaller than the value specified in the globals count record.</p>
+<p>Assuming</p>
+<pre class="prettyprint">
+100 = AbsoluteIndex(&#64;g0))
+</pre>
+<p>The corresponding PNaCl bitcode records are:</p>
+<pre class="prettyprint">
+3: &lt;0, 0, 0&gt;
+3: &lt;1, 3&gt;
+3: &lt;4, 1&gt;
+3: &lt;4, 100, 8&gt;
+3: &lt;4, 110, 7&gt;
+</pre>
+</section><section id="compound-initializer">
+<h3 id="compound-initializer">Compound Initializer</h3>
+<p>The compound initializer record must immediately follow a global
+variable/constant address record. It defines how many (non-compound) initializer
+records are used to define the initializer. The size of the corresponding memory
+is the sum of the bytes needed for each of the succeeding initializers.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+initializers N {                                &lt;A&gt;
+ ...
+}
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;1, N&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>Defines that the next <em>N</em> initializers should be associated with the global
+address of the previous record. <em>A</em> is the (optional) abbreviation index
+associated with the record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+ExpectedInitializers == 1
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+ExpectedInitializers = N;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+const &#64;g1 =
+  initializers 3 {
+    {4, 5, 6, 7}
+    reloc &#64;f1;
+    {99, 66, 22, 12}
+  }
+</pre>
+<p>The corresponding PNaCl records are:</p>
+<pre class="prettyprint">
+3: &lt;0, 0, 1&gt;
+3: &lt;1, 3&gt;
+3: &lt;3, 4, 5, 6, 7&gt;
+3: &lt;4, 1&gt;
+3: &lt;3, 99, 66, 22, 12&gt;
+</pre>
+</section></section><section id="valuesymtab-block">
+<h2 id="valuesymtab-block">Valuesymtab Block</h2>
+<p>TODO(kschimpf)</p>
+</section><section id="module-block">
+<h2 id="module-block">Module Block</h2>
+<p>The module block, like all blocks, are enclosed in a pair of enter/exit records,
+using block ID 8. A well-formed module block consists The following records (in
+order):</p>
+<dl class="docutils">
+<dt>A version record</dt>
+<dd>The version record communicates which version of the PNaCl bitcode
+reader/writer should be used. Note that this is different than the PNaCl
+bitcode (ABI) verion. The PNaCl bitcode (ABI) version defines what is
+expected in records, and is defined in the header record of the bitcode
+file. The version record defines the version of the PNaC bitcode
+reader/writer to use to convert records into bit sequences.</dd>
+<dt>Optional local abbreviations</dt>
+<dd>Defines a list of local abbreviations to use for records within the module
+block.</dd>
+<dt>An abbreviations block</dt>
+<dd>The abbreviations block defines user-defined, global abbreviations that are
+used to convert PNaCl records to bit sequences in blocks following the
+abbreviations block.</dd>
+<dt>A types block</dt>
+<dd>The types block defines the set of all types used in the program.</dd>
+<dt>A non-empty sequence of function address records</dt>
+<dd>Each record defines a function address used by the program. Function
+addresses must either be external, or defined internally by the program. If
+they are defined by the program, there must be a function block (appearing
+later in the module) that defines the sequence of instructions for each
+defined function.</dd>
+<dt>A globals block defining the global variables.</dt>
+<dd>This block defines the set of global variable (addresses) used by the
+program. In addition to the addresses, each global variable also defines how
+the corresponding global variable is initialized.</dd>
+<dt>An optional value symbol table block.</dt>
+<dd>This block, if defined, provides textual names for function and global
+variable addresses (previously defined in the module). Note that only names
+for instrinsic functions must be provided. Any additional names are hints
+that may (or may not) be used by the PNaCl translator, and be available for
+debugging when executed.</dd>
+<dt>A sequence of function blocks.</dt>
+<dd>Each function block defines the corresponding control flow graph for each
+defined function. The order of function blocks is used to associate them with
+function addresses.  The order of the defined function blocks must follow the
+same order as the corresponding function addresses defined in the module
+block.</dd>
+</dl>
+<p>Descriptions of the abbreviations [ref], types [ref], global variables [ref],
+value symbol table [ref], and function [ref] blocks are not provided here. See
+the appropriate reference for more details. The following subsections describe
+each of the records that can appear in a module block.</p>
+<section id="version">
+<h3 id="version">Version</h3>
+<p>The version record defines the implementation of the PNaCl reader/writer to
+use. That is, the implementation that converts PNaCl records to bit
+sequences. Note that this is different than the PNaCl version of the bitcode
+file (encoded in the header record of the bitcode file).  The PNaCl version
+defines the valid forms of PNaCl records. The version record is specific to the
+PNaCl version, and may have different values for different PNaCl versions.</p>
+<p>Note that currently, only PNaCl bitcode version 2, and version record value 1 is
+defined.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+version N;                                  &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;1, N&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The version record defines which PNaCl reader/writer rules should be
+followed. <em>N</em> is the version number. Currently <em>N</em> must be 1. Future versions of
+PNaCl may define additional legal values. <em>A</em> is the (optional) abbreviation
+index associated with the record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+</pre>
+<p><em>Examples</em></p>
+<pre class="prettyprint">
+version 1;
+</pre>
+<p>The corresponding record is:</p>
+<pre class="prettyprint">
+3: &lt;1, 1&gt;
+</pre>
+</section><section id="function-address">
+<h3 id="function-address">Function Address</h3>
+<p>A function address record defines a function address. Defining function
+addresses can also imply a corresponding implementation. <em>Defined</em> function
+addresses define implementations while <em>declared</em> function addresses do not.</p>
+<p>The implementation of a <em>defined</em> function address is provided by a
+corresponding function block, appearing later in the module block. The
+association of defining function address with the corresponding function block
+is based on position.  The <em>Nth</em> defining function address record, in the module
+block, has its implementation in the <em>Nth</em> function block of that module block.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+PN LN T0 &#64;fN ( T1 , ... , TM );                 &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;8, T, C, P, L&gt;
+</pre>
+<p><strong>Semnatics</strong></p>
+<p>Defines the function address <em>&#64;fN</em>. <em>PN</em> is the name that specifies
+the prototype value <em>P</em> associated with the function. A function
+address is defining only if <em>P==0</em>. Otherwise, it is only declared.
+The type of the function is defined by function type <em>&#64;tT</em>. <em>L</em>
+is the linkage specification corresponding to name <em>LN</em>. <em>C</em> is the
+calling convention used by the function. <em>A</em> is the
+(optional) abbreviation associated with the record.</p>
+<p>Note that the function signature must be defined by a function type in the types
+block. Hence, the return value must either be a primitive type, type <em>void</em>, or
+a vector type.  Parameter types can be a primitive or vector type.  For the
+integral types, only i32 and i64 can be used for a return or parameter type. All
+other integer types are not allowed.</p>
+<p>Valid prototype names <em>PN</em>, and corresponding <em>P</em> values, are:</p>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">P</th>
+<th class="head">PN</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>1</td>
+<td>declare</td>
+</tr>
+<tr class="row-odd"><td>0</td>
+<td>define</td>
+</tr>
+</tbody>
+</table>
+<p>Valid linkage names <em>LN</em>, and corresponding <em>L</em> values, are:</p>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">L</th>
+<th class="head">LN</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>3</td>
+<td>internal</td>
+</tr>
+<tr class="row-odd"><td>0</td>
+<td>external</td>
+</tr>
+</tbody>
+</table>
+<p>Currently, only one calling convention <em>C</em> is supported:</p>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">C</th>
+<th class="head">Calling Convention</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>0</td>
+<td>C calling convention</td>
+</tr>
+</tbody>
+</table>
+<p><strong>Constraint</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+T = TypeID(TypeOf(T0 ( T1 , ... , TN )))
+N = NumFuncAddresses
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumFuncAddresses;
+TypeOf(&#64;fN) = TypeOf(TypeID(i32));
+TypeOfFcn(&#64;fN) = TypeOf(&#64;tT);
+
+if PN == 0:
+  DefiningFcnIDs += &#64;FN;
+  ++NumDefinedFunctionAddresses;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+module {
+  ...
+  types {
+    &#64;t0 = void;
+    &#64;t1 = i32;
+    &#64;t3 = float;
+    &#64;t4 = void (i32, float);
+    &#64;t5 = i32 ();
+  }
+  ...
+  declare external void &#64;f0(i32, float);
+  define internal i32 &#64;f1();
+</pre>
+<p>This defines function addresses <em>&#64;f0</em> and <em>&#64;f1</em>. Function address <em>&#64;f0</em> is
+defined externally while <em>&#64;f1</em> has an implementation (defined by a corresponding
+function block). The type signature of <em>&#64;f0</em> is defined by type <em>&#64;t4</em> while the
+type signature of <em>&#64;f1</em> is <em>&#64;t5</em>.</p>
+<p>The corresopnding records for these two function addresses are:</p>
+<pre class="prettyprint">
+3: &lt;8, 4, 0, 1, 0&gt;
+3: &lt;8, 5, 0, 0, 1&gt;
+</pre>
+</section></section><section id="constants-blocks">
+<h2 id="constants-blocks">Constants Blocks</h2>
+<p>TODO(kschimpf)</p>
+</section><section id="function-blocks">
+<h2 id="function-blocks">Function Blocks</h2>
+<p>A function block defines the implementation of a <em>defined</em> function address. The
+function address it defines is based on the position of the corresponding
+<em>defined</em> function address. The Nth <em>defined</em> function address always
+corresponds to the Nth function block in the module block.</p>
+<p>A function definition contains a list of basic block, forming the CFG (control
+flow graph). Each basic block contains a list of instructions, and ends with a
+<em>terminator</em> [ref] (branch) instruction.</p>
+<p>Basic blocks are not represented by records. Rather, context is implicit. The
+first basic block begins with the first instruction record in the function
+block.  Blocks boundaries are determined by <em>terminator</em> instructions. The
+instruction that follows a temrinator instruction begins a new basic block.</p>
+<p>The first basic block in a function is special in two ways: it is immediately
+executed on entrance to the function, and it is not allowed to have predecessor
+basic blocks (i.e. there can&#8217;t be any branches to the entry block of a
+function). Because the entry block has no predecessors, it also can&#8217;t have any
+<em>PHI nodes</em> [ref].</p>
+<p>The parameters are implied by the type of the corresponding function
+address. One parameter is defined for each argument of the function type
+signature.</p>
+<p>The number of basic blocks are defined by the count record. Each termimintor
+instruction ends the current basic block, and the next instruction begins a new
+basic block.  Basic blocks are numbered by the order they appear (starting with
+index 0). Basic block IDs have the form <em>%bN</em>, where <em>N</em> corresponds to the
+position of the basic block within the function block.</p>
+<p>Each instruction, within a function block, corresponds to a corresponding PNaCl
+record.  The layout of a function block is the (basic block) count record,
+followed by a sequence of instruction records.</p>
+<p>For readability, PNaClAsm introduces block IDs. These block IDs do not
+correspond to PNaCl records, since basic block boundaries are defined
+implicitly, after terminator instructions. They appear only for readability.</p>
+<p>Operands are typically defined using an <em>absolute index</em> [ref]. This absolute
+index implicitly encodes function addresses, global addresses, parameters,
+constants, and instructions that generate values. The encoding takes advantage
+of the implied ordering of these values in the bitcode file, defining a block of
+indices for each kind of identifier.  That is, Indices are ordered by putting
+function identifier indices first, followed by global address identifiers,
+followed by parameter identifiers, followed by constant identifiers, and lastly
+instruction value identifiers.</p>
+<p>Most operands of instructions are encoded using a relative index value, rather
+than abolute. The is done because most instruction operands refer to values
+defined earlier in the (same) basic block.  As a result, the relative distance
+(back) from the next value defining instruction is frequently a small
+number. Small numbers tend to require less bits when they are converted to bit
+sequences.</p>
+<p>The following subsections define records that can appear in a function block.</p>
+<section id="function-enter">
+<h3 id="function-enter">Function enter</h3>
+<p>PNaClAsm defines a function enter block construct. The corresponding record is
+simply an enter block record, with BlockID value 12. All context about the
+defining address is implicit by the position of the function block, and the
+corresponding defining function address. To improve readability, PNaClAsm
+includes the function signature into the syntax rule.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+function TR &#64;fN ( T0 %p0, ... , TM %pM) {             &lt;B&gt;
+</pre>
+<p><strong>Record</strong></p>
+<blockquote>
+<div>1: &lt;65535, 12, B&gt;</div></blockquote>
+<p><strong>Semantics</strong></p>
+<p><em>B</em> is the number of bits reserved for abbreviations in the block. See
+enter block records [ref] for more details.</p>
+<p>The value of <em>N</em> corresponds the the positional index of the corresponding
+defining function address this block is associated with. <em>M</em> is the number of
+defined paramaters (minus one) in the function heading.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+N == NumFcnImpls
+&#64;fN in DefiningFcnIDs
+TypeOfFcn(&#64;fN) == TypeOf(TypeID(TR (T0, ... , TM)))
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumFcnImpls;
+EnclosingFcnID = &#64;fN;
+NumBasicBlocks = 0;
+ExpectedBlocks = 0;
+NumParams = M;
+for I in [0..M]:
+  TypeOf(%pI) = TypeOf(TypeID(TI));
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+types {
+  ...
+  &#64;t10 = void (i32, float);
+  ...
+}
+...
+define internal void &#64;f12(i32, float);
+...
+function void &#64;f12(i32 %p0, float %p1) {
+...
+}
+</pre>
+<p>defines the enter block record:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+</pre>
+</section><section id="id3">
+<h3 id="id3">Count Record</h3>
+<p>The count record, within a function block, defines the number of basic blocks
+used to define the function implementation. It should be the first record in the
+function block.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+  blocks: N;                                    &lt;A&gt;
+%b0:
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;1, N&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The count record defines the number <em>N</em> of basic blocks in the implemented
+function. <em>A</em> is the (optional) abbreviation associated with the record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+ExpectedBasicBlocks = 0
+NumBasicBlocks = 0
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+ExpectedBlocks = N;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+blocks: 5
+</pre>
+<p>The corresponding PNaCl bitcode record is:</p>
+<pre class="prettyprint">
+3: &lt;1, 5&gt;
+</pre>
+</section><section id="terminator-instructions">
+<h3 id="terminator-instructions">Terminator Instructions</h3>
+<p>Terminator instructions are instructions that appear in a function block, and
+define the end of the current basic block. A terminator instuction indicates
+which block should be executed after the current block is finished. The function
+block is well formed only if the number of terminator instructions, in the
+function block, corresponds to the value defined by the corresponding count
+block.</p>
+<section id="return-void-instruction">
+<h4 id="return-void-instruction">Return Void Instruction</h4>
+<p>The return void instruction is used to return control from a function back to
+the caller, without returning any value.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+  ret;                                          &lt;A&gt;
+%bB:
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;10&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The return instruction returns control to the calling function.</p>
+<p><em>B</em> is the number associated with the next basic block. Label <em>%bB:</em> only
+appears if <em>B &lt; ExpectedBasicBlocks</em>. That is, the label is omitted only if this
+terminator instruction is the last instruction in the function block.  <em>A</em> is
+the (optional) abbreviation index associated with the record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+B == NumBasicBlocks + 1
+NumBasicBlocks &lt; ExpectedBasicBLocks
+ReturnType(TypeOf(EnclosingFcnID)) == void
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumBasicBlocks;
+</pre>
+<p><strong>Examples</strong></p>
+<p>The following shows the implementation of a function that simply returns.</p>
+<pre class="prettyprint">
+function void &#64;f5() {
+  blocks: 1;
+%b0:
+  ret;
+}
+</pre>
+<p>The corresponding PNaCl records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;10&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="return-value-instruction">
+<h4 id="return-value-instruction">Return Value Instruction</h4>
+<p>The return value instruction is used to return control from a function back to
+the caller, including a value. The value must correspond to the return type of
+the enclosing function.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+  ret T V;                                      &lt;A&gt;
+%bB:
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;10, VV&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The return instruction returns control to the calling function, returning the
+provided value.</p>
+<p><em>V</em> is the value to return. Type <em>T</em> must be of the type returned by the
+function.  It must also be the type associated with value <em>V</em>.  <em>A</em> is the
+(optional) abbreviation index associated with the record.</p>
+<p><em>B</em> is the number associated with the next basic block.  Label <em>%bB:</em> only
+appears if <em>B &lt; ExpectedBasicBlocks</em>. That is, the label is omitted only if this
+terminator instruction is the last instruction in the function block.</p>
+<p>The return type <em>T</em> must either be a primitive type, or a vector type. If the
+return type is an integral type, it must be either i32 or i64.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+VV = RelativeIndex(V)
+B = NumBasicBlocks + 1
+NumBasicBlocks &lt; ExpectedBasicBlocks
+T = TypeOf(V) = ReturnType(TypeOf(EnclosingFcnID))
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumBasicBlocks;
+</pre>
+<p><strong>Examples</strong></p>
+<p>The following shows a return statement that returns the value generated by the
+previous instruction:</p>
+<pre class="prettyprint">
+function i32 &#64;f5(i32 %p0) {
+  blocks: 1;
+&#64;b0:
+  ret i32 &#64;p0;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="unconditional-branch-instruction">
+<h4 id="unconditional-branch-instruction">Unconditional Branch Instruction</h4>
+<p>The unconditional branch instruction is used to cause control flow to transfer
+to a different basic block of the function.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+  br %bN;                                       &lt;A&gt;
+%bB:
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;11, N&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The unconditional branch instruction causes control flow to transfer to basic
+block <em>N</em>.  <em>A</em> is the (optional) abbreviation index associated with the record.</p>
+<p><em>B</em> is the number associated with the next basic block. Label <em>%bB:</em> only
+appears if <em>B &lt; ExpectedBasicBlocks</em>. That is, the label is omitted only if this
+terminator instruction is the last instruction in the function block.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+0 &lt; N
+N &lt; ExpectedBasicBlocks
+B = NumBasicBlocks + 1
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumBasicBlocks;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+br %b2;
+</pre>
+<p>This branch instruction branches to the 3rd basic block of the function. It
+defines the following PNaCL record:</p>
+<pre class="prettyprint">
+3: &lt;11, 2&gt;
+</pre>
+</section><section id="conditional-branch-instruction">
+<h4 id="conditional-branch-instruction">Conditional Branch Instruction</h4>
+<p>The conditional branch instruction is used to cause control flow to transfer to
+a different basic block of the function, based on a boolean test condition.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+  br i1 C, %bT, %bBF;                          &lt;A&gt;
+%bB:
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;11, T, F, V&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>Upon execution of a conditional branch instruction, the <em>i1</em> (boolean) argument
+<em>C</em> is evaluated. If the value is <em>true</em>, control flows to basic block
+<em>%bT</em>. Otherwise control flows to basic block <em>%bF</em>.  <em>A</em> is the (optional)
+abbreviation index associated with the record.</p>
+<p><em>B</em> is the number associated with the next basic block. Label <em>%bB:</em> only
+appears if <em>B &lt; ExpectedBasicBlocks</em>. That is, the label is omitted only if this
+terminator instruction is the last instruction in the function block.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+V = RelativeIndex(C)
+0 &lt; T
+B1 &lt; ExpectedBasicBlocks
+0 &lt; F
+B2 &lt; ExpectedBasicBlocks
+B = NumBasicBlocks + 1
+NumBasicBlocks &lt; ExpectedBasicBlocks
+TypeOf(C) == i1
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumBasicBlocks;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f2(i32 %p0, i32 %p1) {
+  blocks: 3;
+%b0:
+  %v0 = cmp eq i32 %p0, %p1;
+  br i1 %v0, %b1, %b2;
+%b1:
+  ret i32 %p0;
+%b2:
+  ret i32 %p1;
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 3&gt;
+3: &lt;28, 2, 1, 32&gt;
+3: &lt;11, 2, 1, 1&gt;
+3: &lt;10, 3&gt;
+3: &lt;10, 2&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="unreachable">
+<h4 id="unreachable">Unreachable</h4>
+<p>The unreachable instruction has no defined semantics. The instruction is used to
+inform the <em>PNaCl translator</em> that control can&#8217;t reach this instruction.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+  unreachable;                                  &lt;A&gt;
+%bB:
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;15&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>Directive to the <em>PNaCl translator</em> that this instruction is unreachable.  <em>A</em>
+is the (optional) abbreviation index associated with the record.</p>
+<p><em>B</em> is the number associated with the next basic block. Label <em>%bB:</em> only
+appears if <em>B &lt; ExpectedBasicBlocks</em>. That is, the label is omitted only if this
+terminator instruction is the last instruction in the function block.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+B = NumBasicBlocks + 1
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumBasicBlocks;
+</pre>
+<p><strong>Examples</strong></p>
+<p>TODO(kschimpf)</p>
+</section><section id="switch-instruction">
+<h4 id="switch-instruction">Switch Instruction</h4>
+<p>TODO(kschimpf)</p>
+</section></section><section id="integer-binary-inststructions">
+<h3 id="integer-binary-inststructions">Integer Binary Inststructions</h3>
+<p>Binary instructions are used to do most of the computation in a program. This
+section focusses on binary instructions that operator on integral values, or
+vectors of integral values.</p>
+<p>All binary operations require two operands of the same type, execute an
+operation on them, and produce a value. The value may represent multiple values
+if the type is a vector type.  The result value always has the same type as its
+operands.</p>
+<p>Some integer binary operations can be applied to both signed and unsigned
+integers. Others, the sign is significant. In general, if the sign plays a role
+in the instruction, the sign information is encoded into the name of the
+instruction.</p>
+<p>For most binary operations (except some of the logical operations), integral
+type i1 is disallowed.</p>
+<section id="integer-add">
+<h4 id="integer-add">Integer Add</h4>
+<p>The integer add instruction returns the sum of its two arguments. Both arguments
+and the result must be of the same type. That type must be integral, or an
+integral vector type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = add T V1, V2;                             &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<blockquote>
+<div>AA: &lt;2, VV1, VV2, 0&gt;</div></blockquote>
+<p><strong>Semantics</strong></p>
+<p>The integer add instruction returns the sum of its two arguments. Arguments <em>V1</em> and
+<em>V2</em>, and the result <em>%vN</em>, must be of type <em>T</em>. <em>T</em> must be an integral type,
+or an integral vector type.  <em>N</em> is defined by the record position, defining the
+corresponding value generated by the instruction.  <em>A</em> is the (optional)
+abbreviation associated with the corresponding record.</p>
+<p>Overflow conditions are ignored, and the result returned is the mathematical
+result modulo <em>exp(2,n)</em>, where <em>n</em> is the bitwidth of the integer result.</p>
+<p>Because integers are assumed to use a two&#8217;s complement representation,
+this instruction is appropriate for both signed and unsigned integers.</p>
+<p>In the add instruction, Integral type i1 (and vectors on integral type i1) is
+disallowed.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+VV1 = RelativeIndex(V1)
+VV2 = RelativeIndex(V2)
+T = TypeOf(V1) = TypeOf(V2)
+IsInteger(UnderlyingType(T))
+UnderlyingType(T) != i1
+N = NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f0(i32 %p0, i32 %p1) {
+  blocks: 1;
+%b0:
+  %v0 = add i32 %p0, %p1;
+  %v1 = add i32 %p0, %v0;
+  ret i32 %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 0&gt;
+3: &lt;2, 3, 1, 0&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="integer-subtract">
+<h4 id="integer-subtract">Integer Subtract</h4>
+<p>The integer subtract instruction returns the difference of its two arguments.
+Both arguments and the result must be of the same type. That type must be
+integral, or an integral vector type.</p>
+<p>Note: Since there isn&#8217;t a negate instruction, subtraction from constant zero
+should be used to negate values.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = sub T V1, V2;                             &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, VV1, VV2, 1&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The integer subtract returns the difference of its two arguments. Arguments <em>V1</em>
+and <em>V2</em>, and the result <em>%vN</em> must be of type <em>T</em>. <em>T</em> must be an integral
+type, or an integral vector type. <em>N</em> is defined by the record position, defining
+the corresponding value generated by the instruction. <em>A</em> is the (optional)
+abbreviation ¯associated with the corresponding record.</p>
+<p>Underflow conditions are ignored, and the result returned is the mathematical
+result modulo <em>exp(2, n)</em>, where <em>n</em> is the integer bitwidth of the result.</p>
+<p>Because integers are assumed to use a two&#8217;s complement representation,
+this instruction is appropriate for both signed and unsigned integers.</p>
+<p>In the subtract instruction, Integral type i1 is disallowed.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsInteger(UnderlyingType(T))
+UnderlyingType(T) != i1
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f0(i32 %p0, i32 %p1) {
+  blocks: 1;
+%b0:
+  %v0 = sub i32 %p0, %p1;
+  %v1 = sub i32 %p0, %v0;
+  ret i32 %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 1&gt;
+3: &lt;2, 3, 1, 1&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="integer-multiply">
+<h4 id="integer-multiply">Integer Multiply</h4>
+<p>The integer multiply instruction returns the product of its two arguments.  Both
+arguments and the result must be of the same type. That type must be integral,
+or an integral based vector type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+&amp;vN = mul T V1, V2;                             &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, VV1, VV2, 2&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The intebger multiply instruction returns the product of its two
+arguments. Arguments <em>V1</em> and <em>V2</em>, and the result <em>%vN</em>, must be of type <em>T</em>.
+<em>T</em> must be an integral type, or an integral vector type. <em>N</em> is defined by the
+record position, defining the corresponding value generated by the
+instruction. <em>A</em> is the (optional) abbreviation associated with the
+corresponding record.</p>
+<p>Overflow conditions are ignored, and the result returned is the mathematical
+result modulo <em>exp(2, n)</em>, where <em>n</em> is the bitwidth of the result.</p>
+<p>Because integers are assumed to use a two&#8217;s complement representation,
+this instruction is appropriate for both signed and unsigned integers.</p>
+<p>In the subtract instruction, Integral type i1 is disallowed.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsInteger(UnderlyingType(T))
+UnderlyingType(T) != i1
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f0(i32 %p0, i32 %p1) {
+  blocks: 1;
+%b0:
+  %v0 = mul i32 %p0, %p1;
+  %v1 = mul i32 %v0, %p1;
+  ret i32 %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 2&gt;
+3: &lt;2, 1, 2, 2&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="signed-integer-divide">
+<h4 id="signed-integer-divide">Signed Integer Divide</h4>
+<p>The signed integer divide instruction returns the quotient of its two arguments.
+Both arguments and the result must be of the same type. That type must be
+integral, or an integral vector type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = sdiv T V1, V2;                             &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, VV1, VV2, 4&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The divide instruction returns the quotient of its two arguments. Arguments <em>V1</em>
+and <em>V2</em>, and the result <em>%vN</em>, must be of type <em>T</em>. <em>T</em> must be a integral
+type, or an integral vector type. <em>N</em> is defined by the record position,
+defining the corresponding value generated by the instruction. <em>A</em> is the
+(optional) abbreviation associated with the corresponding record.</p>
+<p>Signed values are assumed.  Note that signed and unsigned integer division are
+distinct operations. For unsigned integer division use the unsigned integer
+divide instruction (udiv).</p>
+<p>In the signed integer divide instruction, integral type i1 is
+disallowed. Integer division by zero is guaranteed to trap. Overflow is also
+undefined.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsInteger(UnderlyingType(T))
+UnderlyingType(T) != i1
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f0(i32 %p0, i32 %p1) {
+  blocks: 1;
+%b0:
+  %v0 = sdiv i32 %p0, %p1;
+  %v1 = sdiv i32 %v0, %p1;
+  ret i32 %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 4&gt;
+3: &lt;2, 1, 2, 4&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="unsigned-integer-divide">
+<h4 id="unsigned-integer-divide">Unsigned Integer Divide</h4>
+<p>The unsigned integer divide instruction returns the quotient of its two
+arguments. Both the arguments and the result must be of the same type. That type
+must be integral, or an integral vector type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = udiv T V1, V2;                            &lt;a&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, A1, A2, 3&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The unsigned integer divide instruction returns the quotient of its two
+arguments. Arguments <em>V1</em> and <em>V2</em>, and the result <em>%vN</em>, must be of type
+<em>T</em>. <em>T</em> must be an integral type, or an integral vector type.  <em>N</em> is defined
+by the record position, defining the corresponding value generated by the
+instruction. <em>A</em> is the (optional) abbreviation associated with the
+corresponding record.</p>
+<p>Unsigned integral values are assumed.  Note that signed and unsigned integer
+division are distinct operations. For signed integer division use the signed
+integer divide instruction (sdiv).</p>
+<p>In the unsigned integer divide instruction, Integral type i1 is
+disallowed. Division by zero is guaranteed to trap. Overflow is also undefined.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsInteger(UnderlyingType(T))
+UnderlyingType(T) != i1
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f0(i32 %p0, i32 %p1) {
+  blocks: 1;
+%b0:
+  %v0 = udiv i32 %p0, %p1;
+  %v1 = udiv i32 %v0, %p1;
+  ret i32 %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 3&gt;
+3: &lt;2, 1, 2, 3&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="signed-integer-remainder">
+<h4 id="signed-integer-remainder">Signed Integer Remainder</h4>
+<p>The signed integer remainder instruction returns the remainder of the quotient
+of its two arguments. Both arguments and the result must be of the same
+type. That type must be integral, or an integral based vector type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = srem T V1, V2;                             &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, VV1, VV2, 6&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The signed integer remainder instruction returns the remainder of the quotient
+of its two arguments. Arguments <em>V1</em> and <em>V2</em>, and the result <em>%vN</em>, must be of
+type <em>T</em>. <em>T</em> must be a integral type, or an integral vector type. <em>N</em> is
+defined by the record position, defining the corresponding value generated by
+the instruction. <em>A</em> is the (optional) abbreviation associated with the
+corresponding record.</p>
+<p>Signed values are assumed.  Note that signed and unsigned integer division are
+distinct operations. For unsigned integer division use the unsigned integer
+remainder instruction (urem).</p>
+<p>In the signed integer remainder instruction, Integral type i1 is disallowed.
+Division by zero is guaranteed to trap. Overflow is also undefined.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsInteger(UnderlyingType(T))
+UnderlyingType(T) != i1
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f0(i32 %p0, i32 %p1) {
+  blocks: 1;
+%b0:
+  %v0 = srem i32 %p0, %p1;
+  %v1 = srem i32 %v0, %p1;
+  ret i32 %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 6&gt;
+3: &lt;2, 1, 2, 6&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="unsigned-integer-remainder-instruction">
+<h4 id="unsigned-integer-remainder-instruction">Unsigned Integer Remainder Instruction</h4>
+<p>The unsigned integer remainder instruction returns the remainder of the quotient
+of its two arguments. Both the arguments and the result must be of the same
+type. The type must be integral, or an integral vector type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = urem T V1, V2;                            &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, A1, A2, 5&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The unsigned integer remainder instruction returns the remainder of the quotient
+of its two arguments. Arguments <em>V1</em> and <em>V2</em>, and the result <em>%vN</em>, must be of
+type <em>T</em>. <em>T</em> must be an integral type, or an integral vector type.  <em>N</em> is
+defined by the record position, defining the corresponding value generated by
+the instruction. <em>A</em> is the (optional) abbreviation associated with the
+corresponding record.</p>
+<p>Unsigned values are assumed. Note that signed and unsigned integer division are
+distinct operations. For signed integer division use the remainder instruction
+(srem).</p>
+<p>In the unsigned integer remainder instruction, Integral type i1 is disallowed.
+Division by zero is guaranteed to trap. Overflow is also undefined.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsInteger(UnderlyingType(T))
+UnderlyingType(T) != i1
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f0(i32 %p0, i32 %p1) {
+  blocks: 1;
+%b0:
+  %v0 = srem i32 %p0, %p1;
+  %v1 = srem i32 %v0, %p1;
+  ret i32 %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 5&gt;
+3: &lt;2, 1, 2, 5&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="shift-left">
+<h4 id="shift-left">Shift left</h4>
+<p>The (integer) shift left instruction returns the first operand, shifted to the
+left a specified number of bits with zero fill. The shifted value must be
+integral, or an integral vector type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = shl T V1, V2;                             &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, VV1, VV2, 7&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>This instruction performs a shift left operation. Argument <em>V1</em> and the result
+<em>%vN</em> must be of type <em>T</em>. <em>T</em> nust be an integral, or a vector of
+integrals. <em>V2</em> must be an integral type. <em>N</em> is defined by the record position,
+defining the corresponding value generated by the instruction.  <em>A</em> is the
+(optional) abbreviation associated with the corresponding record.</p>
+<p><em>V2</em> is assumed to be unsigned.  The least significant bits of the result will
+be filled with zero bits after the shift. If <em>V2</em> is (statically or dynamically)
+is negative or equal to or larger than the number of bits in <em>V1</em>, the result is
+undefined. If the arguments are vectors, each vector element of <em>V1</em> is shifted
+by the corresponding shift amount in <em>V2</em>.</p>
+<p>In the shift left instruction, Integral type i1 is disallowed for either
+argument.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1)
+IsInteger(TypeOf(V2))
+IsInteger(UnderlyingType(T))
+UnderlyingType(T) != i1
+UnderlyingType(TypeOf(V2)) != i1
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f0(i32 %p0, i32 %p1) {
+  blocks: 1;
+%b0:
+  %v0 = shl i32 %p0, %p1;
+  %v1 = shl i32 %v0, %p1;
+  ret i32 %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 7&gt;
+3: &lt;2, 1, 2, 7&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="logical-shift-right">
+<h4 id="logical-shift-right">Logical Shift right</h4>
+<p>The logical shift right instruction returns the first operand, shifted
+to the right a specified number of bits with zero fill.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = lshr T V1, V2;                            &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, VV1, VV2, 8&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>This instruction performs a logical shift right operation. Arguments <em>V1</em> and
+the result <em>%vN</em> must be of type <em>T</em>. <em>T</em> nust be an integral, or a vector of
+integrals. <em>V2</em> must be an integral type. <em>N</em> is defined by the record position,
+defining the corresponding value generated by the instruction.  <em>A</em> is the
+(optional) abbreviation associated with the corresponding record.</p>
+<p><em>V2</em> is assumed to be unsigned. The most significant bits of the result will be
+filled with zero bits after the shift. If <em>V2</em> is (statically or dynamically)
+negative or equal to or larger than the number of bits in <em>V1</em>, the result is
+undefined. If the arguments are vectors, each vector element of <em>V1</em> is shifted
+by the corresponding shift amount in <em>V2</em>.</p>
+<p>In the logical shift right instruction, Integral type i1 is disallowed for
+either argument.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA = AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1)
+IsInteger(TypeOf(V2))
+IsInteger(UnderlyingType(T))
+UnderlyingType(T) != i1
+UnderlyingType(TypeOf(V2)) != i1
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f0(i32 %p0, i32 %p1) {
+  blocks: 1;
+%b0:
+  %v0 = lshr i32 %p0, %p1;
+  %v1 = lshr i32 %v0, %p1;
+  ret i32 %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 8&gt;
+3: &lt;2, 1, 2, 8&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="arithmetic-shift-right">
+<h4 id="arithmetic-shift-right">Arithmetic Shift Right</h4>
+<p>The arithmetic shift right instruction returns the first operand,
+shifted to the right a specified number of bits with sign extension.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = ashr T V1, V2;                            &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, VV1, VVA2, 9&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>This instruction performs an arithmetic shift right operation. Arguments <em>V1</em>
+and the result <em>%vN</em> must be of type <em>T</em>. <em>T</em> nust be an integral, or a vector
+of integrals. <em>V2</em> must be an integral type. <em>N</em> is defined by the record
+position, defining the corresponding value generated by the instruction.  <em>A</em> is
+the (optional) abbreviation associated with the corresponding record.</p>
+<p><em>V2</em> is assumed to be unsigned. The most significant bits of the result will be
+filled with the sign bit of <em>V1</em>. If <em>V2</em> is (statically or dynamically)
+negative or equal to or larger than the number of bits in <em>V1</em>, the result is
+undefined. If the arguments are vectors, each vector element of <em>V1</em> is shifted
+by the corresponding shift amount in <em>V2</em>.</p>
+<p>In the arithmetic shift right instruction, integral type i1 is disallowed for
+either argument.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1)
+IsInteger(TypeOf(V2))
+UnderlyingType(T) != i1
+UnderlyingType(TypeOf(V2)) != i1
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f0(i32 %p0, i32 %p1) {
+  blocks: 1;
+%b0:
+  %v0 = ashr i32 %p0, %p1;
+  %v1 = ashr i32 %v0, %p1;
+  ret i32 %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 9&gt;
+3: &lt;2, 1, 2, 9&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="logical-and">
+<h4 id="logical-and">Logical And</h4>
+<p>The <em>and</em> instruction returns the bitwise logical and of its two operands.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = and T V1, V2;                             &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, VV1, VV2, 10&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>This instruction performs a bitwise logical and of its arguments.  Arguments
+<em>V1</em> and <em>V2</em>, and the result <em>%vN</em> must be of type <em>T</em>. <em>T</em> nust be an
+integral, or a vector of integrals. <em>N</em> is defined by the record position,
+defining the corresponding value generated by the instruction.  <em>A</em> is the
+(optional) abbreviation associated with the corresponding record.</p>
+<p>The truth table used for the <em>and</em> instruction is:</p>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Arg 1</th>
+<th class="head">Arg 2</th>
+<th class="head">Result</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>0</td>
+<td>0</td>
+<td>0</td>
+</tr>
+<tr class="row-odd"><td>0</td>
+<td>1</td>
+<td>0</td>
+</tr>
+<tr class="row-even"><td>1</td>
+<td>0</td>
+<td>0</td>
+</tr>
+<tr class="row-odd"><td>1</td>
+<td>1</td>
+<td>1</td>
+</tr>
+</tbody>
+</table>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsInteger(UnderlyingType(T)))
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f0(i32 %p0, i32 %p1) {
+  blocks: 1;
+%b0:
+  %v0 = and i32 %p0, %p1;
+  %v1 = and i32 %v0, %p1;
+  ret i32 %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 10&gt;
+3: &lt;2, 1, 2, 10&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="logical-or">
+<h4 id="logical-or">Logical Or</h4>
+<p>The <em>or</em> instruction returns the bitwise logical inclusive or of its
+two operands.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = or T V1, V2;                              &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, VV1, VV2, 11&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>This instruction performs a bitwise logical inclusive or of its arguments.
+Arguments <em>V1</em> and <em>V2</em>, and the result <em>%vN</em> must be of type <em>T</em>. <em>T</em> nust be
+an integral, or a vector of integrals. <em>N</em> is defined by the record position,
+defining the corresponding value generated by the instruction.  <em>A</em> is the
+(optional) abbreviation associated with the corresponding record.</p>
+<p>The truth table used for the <em>or</em> instruction is:</p>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Arg 1</th>
+<th class="head">Arg 2</th>
+<th class="head">Result</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>0</td>
+<td>0</td>
+<td>0</td>
+</tr>
+<tr class="row-odd"><td>0</td>
+<td>1</td>
+<td>1</td>
+</tr>
+<tr class="row-even"><td>1</td>
+<td>0</td>
+<td>1</td>
+</tr>
+<tr class="row-odd"><td>1</td>
+<td>1</td>
+<td>1</td>
+</tr>
+</tbody>
+</table>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsInteger(UnderlyingType(T)))
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f0(i32 %p0, i32 %p1) {
+  blocks: 1;
+%b0:
+  %v0 = or i32 %p0, %p1;
+  %v1 = or i32 %v0, %p1;
+  ret i32 %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 11&gt;
+3: &lt;2, 1, 2, 11&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="logical-xor">
+<h4 id="logical-xor">Logical Xor</h4>
+<p>The <em>xor</em> instruction returns the bitwise logical exclusive or of its
+two operands.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = xor T V1, V2;                             &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, VV1, VV2, 12&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>This instruction performs a bitwise logical exclusive or of its
+arguments.  Arguments <em>V1</em> and <em>V2</em>, and the result <em>%vN</em> must be of
+type <em>T</em>. <em>T</em> nust be an integral, or a vector of integrals. <em>N</em> is
+defined by the record position, defining the corresponding value
+generated by the instruction.  <em>A</em> is the (optional) abbreviation
+associated with the corresponding record.</p>
+<p>The truth table used for the <em>or</em> instruction is:</p>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Arg 1</th>
+<th class="head">Arg 2</th>
+<th class="head">Result</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>0</td>
+<td>0</td>
+<td>0</td>
+</tr>
+<tr class="row-odd"><td>0</td>
+<td>1</td>
+<td>1</td>
+</tr>
+<tr class="row-even"><td>1</td>
+<td>0</td>
+<td>1</td>
+</tr>
+<tr class="row-odd"><td>1</td>
+<td>1</td>
+<td>0</td>
+</tr>
+</tbody>
+</table>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+A1 == RelativeIndex(V1)
+A2 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsInteger(UnderlyingType(T)))
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function i32 &#64;f0(i32 %p0, i32 %p1) {
+  blocks: 1;
+%b0:
+  %v0 = xor i32 %p0, %p1;
+  %v1 = xor i32 %v0, %p1;
+  ret i32 %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 12&gt;
+3: &lt;2, 1, 2, 12&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section></section><section id="floating-binary-inststructions">
+<h3 id="floating-binary-inststructions">Floating Binary Inststructions</h3>
+<p>Floating Binary instructions require two operands of the same type, execute an
+operation on them, and produce a value. The value may represent multiple values
+if the type is a vector type.  The result value always has the same type as its
+operands.</p>
+<section id="float-add">
+<h4 id="float-add">Float Add</h4>
+<p>The float add instruction returns the sum of its two arguments. Both arguments
+and the result must be of the same type. That type must be floating, or a
+floating vector type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = add T V1, V2;                             &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<blockquote>
+<div>AA: &lt;2, VV1, VV2, 0&gt;</div></blockquote>
+<p><strong>Semantics</strong></p>
+<p>The float add instruction returns the sum of its two arguments. Arguments <em>V1</em>
+and <em>V2</em> and the result <em>%vN</em> must be of type <em>T</em>. <em>T</em> must be a floating type,
+or a floating vector type. <em>N</em> is defined by the record position, defining the
+corresponding value generated by the instruction.  <em>A</em> is the (optional)
+abbreviation associated with the corresponding record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsFloat(UnderlyingType(T))
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function float &#64;f0(float %p0, float %p1) {
+  blocks: 1;
+%b0:
+  %v0 = add float %p0, %p1;
+  %v1 = add float %p0, %v0;
+  ret float %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 0&gt;
+3: &lt;2, 3, 1, 0&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="float-subtract">
+<h4 id="float-subtract">Float Subtract</h4>
+<p>The floatsubtract instruction returns the difference of its two arguments. Both
+arguments and the result must be of the same type. That type must be a floating,
+or an floating based vector type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = sub T V1, V2;                             &lt;a&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, VV1, VV2, 1&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The float subtract instruction returns the difference of its two
+arguments. Arguments <em>V1</em> and <em>V2</em>, and the result <em>%vN</em> must be of type
+<em>T</em>. <em>T</em> must be an floating type, or a floating vector type. <em>N</em> is defined by
+the record position, defining the corresponding value generated by the
+instruction. <em>A</em> is the (optional) abbreviation ¯associated with the
+corresponding record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsFloat(UnderlyingType(T))
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function float &#64;f0(float %p0, float %p1) {
+  blocks: 1;
+%b0:
+  %v0 = sub float %p0, %p1;
+  %v1 = sub float %p0, %v0;
+  ret float %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 1&gt;
+3: &lt;2, 3, 1, 1&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="float-multiply">
+<h4 id="float-multiply">Float Multiply</h4>
+<p>The float multiply instruction returns the product of its two arguments. Both
+arguments and the result must be of the same type. That type must be floating,
+or a floating based vector type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+&amp;vN = mul T V1, V2;                             &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, VV1, VV2, 2&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The multiply instruction returns the product of its two arguments. Arguments
+<em>V1</em> and <em>V2</em>, and the result <em>%vN</em> must be of type <em>T</em>.  <em>T</em> must be an
+floating type, or a floating vector type. <em>N</em> is defined by the record position,
+defining the corresponding value generated by the instruction. <em>A</em> is the
+(optional) abbreviation associated with the corresponding record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsFloat(UnderlyingType(T))
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function float &#64;f0(float %p0, float %p1) {
+  blocks: 1;
+%b0:
+  %v0 = mul float %p0, %p1;
+  %v1 = mul float %p0, %v0;
+  ret float %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 2&gt;
+3: &lt;2, 3, 1, 2&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="float-divide">
+<h4 id="float-divide">Float Divide</h4>
+<p>The float divide instruction returns the quotient of its two arguments. Both
+arguments and the result must be of the same type. That type must be a floating
+type, or a floating based vector type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = div T V1, V2;                             &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, V1, V2, 4&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The float divide instruction returns the quotient of its two
+arguments. Arguments <em>V1</em> and <em>V2</em>, and the result <em>%vN</em> must be of type
+<em>T</em>. <em>T</em> must be a floating type, or a floating vector type. <em>N</em> is defined by
+the record position, defining the corresponding value generated by the
+instruction. <em>A</em> is the (optional) abbreviation associated with the
+corresponding record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV22 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsFloat(UnderlyingType(T))
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function double &#64;f0(double %p0, double %p1) {
+  blocks: 1;
+%b0:
+  %v0 = div double %p0, %p1;
+  %v1 = div double %p0, %v0;
+  ret double %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 4&gt;
+3: &lt;2, 3, 1, 4&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="float-remainder">
+<h4 id="float-remainder">Float Remainder</h4>
+<p>The float remainder instruction returns the remainder of the quotient of its two
+arguments. Both arguments and the result must be of the same type. That type
+must be a floating type, or a floating based vector type.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = rem T V1, V2;                             &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;2, VV1, VV2, 6&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The float remainder instruction returns the remainder of the quotient of its two
+arguments. Arguments <em>V1</em> and <em>V2</em>, and the result <em>%vN</em> must be of type
+<em>T</em>. <em>T</em> must be a floating type, or a floating vector type. <em>N</em> is defined by
+the record position, defining the corresponding value generated by the
+instruction. <em>A</em> is the (optional) abbreviation associated with the
+corresponding record.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV1 == RelativeIndex(V1)
+VV2 == RelativeIndex(V2)
+T == TypeOf(V1) == TypeOf(V2)
+IsFloat(UnderlyingType(T))
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+function double &#64;f0(double %p0, double %p1) {
+  blocks: 1;
+%b0:
+  %v0 = rem double %p0, %p1;
+  %v1 = rem double %p0, %v0;
+  ret double %v1;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;2, 2, 1, 6&gt;
+3: &lt;2, 3, 1, 6&gt;
+3: &lt;10, 1&gt;
+0: &lt;65534&gt;
+</pre>
+</section></section><section id="memory-creation-and-access-instructions">
+<h3 id="memory-creation-and-access-instructions">Memory creation and access Instructions</h3>
+<p>A key design point of SSA-based representation is how it represents
+memory. In PNaCl bitcode files, no memory locations are in SSA
+form. This makes things very simple.</p>
+<section id="alloca-instruction">
+<h4 id="alloca-instruction">Alloca Instruction</h4>
+<p>The <em>alloca</em> instruction allocates memory on the stack frame of the
+currently executing function. This memory is automatically released
+when the function returns to its caller.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = alloca i8, i32 S, align V;                &lt;A&gt;
+%vN = alloca i8, i32 S;                         &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;19, SS, VV&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The <em>alloca</em> instruction allocates memory on the stack frame of the currently
+executing function.  The resulting value is a pointer to the allocated memory
+(i.e. of type i32). <em>S</em> is the number of bytes that are allocated on the
+stack. <em>S</em> must be of integral type i32. <em>V</em> is the aligment of the generated
+stack address. <em>A</em> is the corresponding number of bits associated with the
+record.</p>
+<p>Alignment must be a power of 2. A value of 0 means that the address
+has the ABI alignment of the target. If alignment is not specified,
+zero is used. Alignment on the stack is guaranteed to be aligned to at least
+the boundary specified by the alignment.</p>
+<p>TODO(kschimpf) Other alignment issues?</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+VV == Log2(V+1)
+SS == RelativeIndex(S)
+i32 == TypeOf(S)
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = i32;
+</pre>
+<p><strong>Examples</strong></p>
+<p>The following instructions allocates memory for a 32-bit integer and a
+64-bit floating value:</p>
+<pre class="prettyprint">
+function void &#64;f() {
+  blocks: 1;
+  constants {
+    i32:
+      %c0 = 4;  // == sizeof(i32)
+      %c1 = 8;  // == sizeof(double)
+  }
+%b0:
+  %v0 = alloca i8, i32 %c0;
+  %v1 = alloca i8, i32 %c1;
+  ret;
+}
+</pre>
+<p>Assuming <em>TypeId(i32) == &#64;t1</em>, the corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+1: &lt;65535, 11, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;4, 8&gt;
+3: &lt;4, 16&gt;
+0: &lt;65534&gt;
+3: &lt;19, 2, 0&gt;
+3: &lt;19, 2, 0&gt;
+3: &lt;10&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="load-instruction">
+<h4 id="load-instruction">Load Instruction</h4>
+<p>The <em>load</em> instruction is used to read from memory.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = load T* P, align V;                       &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;20, PP, VV, TT&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The load instruction is used to read from memory. <em>P</em> is identifier of the
+memory address to read. The type of <em>P</em> must be an i32 integer.  <em>T</em> is the type
+of value to read. <em>V</em> is the alignment of the memory address.  <em>A</em> is the
+(optional) abbreviation associated with the record.</p>
+<p>Type <em>T</em> must be an integral or floating type. Both float and double types
+are allowed for floating types. All integral types except i1 is allowed.</p>
+<p>Valid alignment <em>V</em> values are:</p>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head"><em>V</em></th>
+<th class="head">Types</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>1</td>
+<td>i8, i16, i32, i64</td>
+</tr>
+<tr class="row-odd"><td>4</td>
+<td>float</td>
+</tr>
+<tr class="row-even"><td>8</td>
+<td>double</td>
+</tr>
+</tbody>
+</table>
+<p><strong>Constraints</strong></p>
+<blockquote>
+<div>AA == AbbrevIndex(A)
+i32 == TypeOf(P)
+PP == RelativeIndex(P)
+VV == Log2(V+1)
+%tTT == TypeID(T)
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks</div></blockquote>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T;
+</pre>
+<p><strong>Examples</strong></p>
+<p>The following instructions load an i32 integer and a 64-bit floating value:</p>
+<pre class="prettyprint">
+function void &#64;f(i32 %p0) {
+  blocks: 1;
+%b0:
+  %v0 = load i32* %p0, align 1;
+  %v1 = load double* %v0, align 8;
+  ret;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;20, 1, 1&gt;
+3: &lt;20, 1, 4&gt;
+3: &lt;10&gt;
+0: &lt;65534&gt;
+</pre>
+</section><section id="store-instruction">
+<h4 id="store-instruction">Store Instruction</h4>
+<p>The <em>store</em> instruction is used to write to memory.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+store T S, T* P, align V;                     &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;24, PP, SS, VV&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The store instruction is used to write to memory. <em>P</em> is the identifier of the
+memory address to write to.  The type of <em>P</em> must be an i32 integer.  <em>T</em> is the
+type of value to store. <em>S</em> is the value to store, and must be of type <em>T</em>.  <em>V</em>
+is the alignment of the memory address.  <em>A</em> is the (optional) abbreviation
+index associated with the record.</p>
+<p>Type <em>T</em> must be an integral or floating type. Both float and double types
+are allowed for floating types. All integral types except i1 is allowed.</p>
+<p>Valid alignment <em>V</em> values are:</p>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head"><em>V</em></th>
+<th class="head">Types</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>1</td>
+<td>i8, i16, i32, i64</td>
+</tr>
+<tr class="row-odd"><td>4</td>
+<td>float</td>
+</tr>
+<tr class="row-even"><td>8</td>
+<td>double</td>
+</tr>
+</tbody>
+</table>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+i32 == TypeOf(P)
+PP == RelativeIndex(P)
+VV == Log2(V+1)
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Examples</strong></p>
+<p>The following instructions store an i32 integer and a 32-bit floating
+value.</p>
+<pre class="prettyprint">
+function void &#64;f(i32 %p0, i32 %p1, i32 %p2, float %p3) {
+  blocks: 1;
+%b0:
+  store i32 %p1, i32* %p2, align 1;
+  store float %p3, float* %p3, align 4;
+  ret;
+}
+</pre>
+<p>The corresponding records are:</p>
+<pre class="prettyprint">
+1: &lt;65535, 12, 2&gt;
+3: &lt;1, 1&gt;
+3: &lt;24, 4, 3, 1&gt;
+3: &lt;24, 1, 2, 4&gt;
+3: &lt;10&gt;
+0: &lt;65534&gt;
+</pre>
+</section></section><section id="conversion-instructions">
+<h3 id="conversion-instructions">Conversion Instructions</h3>
+<p>Conversion instructions all take a single operand and a type. The
+value is converted to the corresponding type.</p>
+<section id="integer-truncating-instruction">
+<h4 id="integer-truncating-instruction">Integer truncating Instruction</h4>
+<p>The integer truncating instruction takes a value to truncate, and a type
+defining the truncated type. Both types must be integer types, or integral
+vectors of the same size. The bit size of the value must be larger than the bit
+size of the destination type. Equal sized types are not allowed.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = trunc T1 V to T2;                         &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;3, VV, TT2, 0&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The integer truncating instruction takes a value <em>V</em>, and truncates to type
+<em>T2</em>. <em>A</em> is the (optional) abbreviation associated with the corresponding
+record. Both <em>T1</em> and <em>T2</em> must be integer types, or integral vectors of the
+same size.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+TypeOf(V) = T1
+*VV* == RelativeIndex(*V*)
+%tTT2 = TypeID(T2)
+BitSizeOf(UnderlyingType(T1)) &gt; BitSizeOf(UnderlyingType(T2))
+UnderlyingCount(T1) == UnderlyingCount(T2)
+IsInteger(UnderlyingType(T1))
+IsInteger(UnderlyingType(T2))
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T2;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+%v10 = trunc i32 %v9 to i8;
+</pre>
+<p>Assuming</p>
+<pre class="prettyprint">
+&#64;t2 = i8;
+</pre>
+<p>the corresponding record is:</p>
+<pre class="prettyprint">
+&lt;3, 1, 2, 0&gt;
+</pre>
+</section><section id="floating-truncating-instruction">
+<h4 id="floating-truncating-instruction">Floating truncating Instruction</h4>
+<p>The floating truncating instruction takes a value to truncate, and a type
+defining the truncated type. Both types must be floating types, or floating
+vectors of the same size. The bit size of the value must be larger than the bit
+size of the destination type. Equal sized types are not allowed.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = fptrunc T1 V to T2;                       &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;3, VV, TT2, 7&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The floating truncating instruction takes a value <em>V</em>, and truncates to type
+<em>T2</em>. <em>A</em> is the (optional) abbreviation associated with the corresponding
+record. Both <em>T1</em> and <em>T2</em> must be integer types, or integral vectors of the
+same size.</p>
+<p>If the value can&#8217;t fit within the destination type <em>T2</em>, the results are
+undefined.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+TypeOf(V) = T1
+double == UnderlyingType(T1)
+float == UnderlyingType(T2)
+*VV* == RelativeIndex(*V*)
+%tTT2 = TypeID(T2)
+BitSizeOf(UnderlyingType(T1)) &gt; BitSizeOf(UnderlyingType(T2))
+UnderlyingCount(T1) == UnderlyingCount(T2)
+IsFloat(UnderlyingType(T1))
+IsFloat(UnderlyingType(T2))
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T2;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+%v10 = fptrunc double %v9 to float;
+</pre>
+<p>Assuming</p>
+<pre class="prettyprint">
+&#64;t4 = float;
+</pre>
+<p>the corresponding record is:</p>
+<pre class="prettyprint">
+&lt;3, 1, 4, 7&gt;
+</pre>
+</section><section id="zero-extending-instruction">
+<h4 id="zero-extending-instruction">Zero Extending Instruction</h4>
+<p>The zero extending instruction takes an value to cast, and a type to extend it
+to. Both types must be integer types, or integral vectors of the same size. The
+bit size of the value must be smaller than the bitsize of the destination
+type. Equal sized types are not allowed.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = zext T1 V to T2;                          &lt;A&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+AA: &lt;3, VV, TT2, 1&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The zero extending instruction takes a value <em>V</em>, and expands it to type
+<em>T2</em>. <em>I</em> is the (optional) abbreviation associated with the corresponding
+record.  Both <em>T1</em> and <em>T2</em> must be integer types, or vectors of the same number
+of integers.</p>
+<p>The instruction fills the high order bits of the value with zero bits
+until it reaches the size of the destination type. When zero extending
+from i1, the result will always be either 0 or 1.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+AA == AbbrevIndex(A)
+TypeOf(V) = T1
+*VV* == RelativeIndex(*V*)
+%tTT2 = TypeID(T2)
+BitSizeOf(UnderlyingType(T1)) &lt; BitSizeOf(UnderlyingType(T2))
+UnderlyingCount(T1) == UnderlyingCount(T2)
+IsInteger(UnderlyingType(T1))
+IsInteger(UnderlyingType(T2))
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T2;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+%v12 = zext i8 %v11 to i32;
+</pre>
+<p>Assuming</p>
+<pre class="prettyprint">
+&#64;t0 = i32;
+</pre>
+<p>the corresponding record is:</p>
+<pre class="prettyprint">
+&lt;3, 1, 0, 2&gt;
+</pre>
+</section><section id="sign-extending-instruction">
+<h4 id="sign-extending-instruction">Sign Extending Instruction</h4>
+<p>The sign extending instruction takes an value to cast, and a type to
+extend it to. Both types must be integer types, or vectors of the same
+number of integers. The bit size of the value must be smaller than the
+bitsize of the destination type. Equal sized types are not allowed.</p>
+<p><strong>Syntax</strong></p>
+<pre class="prettyprint">
+%vN = sext T1 V to T2;                          &lt;I&gt;
+</pre>
+<p><strong>Record</strong></p>
+<pre class="prettyprint">
+I: &lt;3, VV, TT2, 2&gt;
+</pre>
+<p><strong>Semantics</strong></p>
+<p>The sign extending instruction takes a value <em>V</em>, and expands it to
+type <em>T2</em>. <em>VV</em> is the relative index of <em>V</em>. <em>I</em> is the (optional)
+abbreviation associated with the corresponding record. Both <em>T1</em> and
+<em>T2</em> must be integer types, or vectors of the same number of integers.</p>
+<p>When sign extending, the instruction fills the high order bits of the
+value with the (current) high order bit of the value. When sign
+extending from i1, the extension always results in -1 or 0.</p>
+<p><strong>Constraints</strong></p>
+<pre class="prettyprint">
+TypeOf(V) = T1
+*VV* == RelativeIndex(*V*)
+%tTT2 = TypeID(T2)
+BitSizeOf(UnderlyingType(T1)) &lt; BitSizeOf(UnderlyingType(T2))
+UnderlyingCount(T1) == UnderlyingCount(T2)
+IsInteger(UnderlyingType(T1))
+IsInteger(UnderlyingType(T2))
+N == NumValuedInsts
+NumBasicBlocks &lt; ExpectedBasicBlocks
+</pre>
+<p><strong>Updates</strong></p>
+<pre class="prettyprint">
+++NumValuedInsts;
+TypeOf(%vN) = T2;
+</pre>
+<p><strong>Examples</strong></p>
+<pre class="prettyprint">
+%v12 = sext i8 %v11 to i32;
+</pre>
+<p>Assuming</p>
+<pre class="prettyprint">
+&#64;t0 = i32;
+</pre>
+<p>the corresponding record is:</p>
+<pre class="prettyprint">
+&lt;3, 1, 0, 2&gt;
+</pre>
+</section><section id="fpext">
+<h4 id="fpext">fpext</h4>
+<p>TODO(kschimpf)</p>
+</section><section id="fptoui">
+<h4 id="fptoui">fptoui</h4>
+<p>TODO(kschimpf)</p>
+</section><section id="fptosi">
+<h4 id="fptosi">fptosi</h4>
+<p>TODO(kschimpf)</p>
+</section><section id="sitofp">
+<h4 id="sitofp">sitofp</h4>
+<p>TODO(kschimpf)</p>
+</section><section id="bitcast">
+<h4 id="bitcast">bitcast</h4>
+<p>TODO(kschimpf)</p>
+</section></section><section id="comparison-instructions">
+<h3 id="comparison-instructions">Comparison Instructions</h3>
+<p>TODO(kschimpf): cmp</p>
+</section><section id="other-instructions">
+<h3 id="other-instructions">Other Instructions</h3>
+<p>TODO(kschimpf)</p>
+<section id="phi-instruction">
+<h4 id="phi-instruction">Phi Instruction</h4>
+<p>TODO(kschimpf)</p>
+</section><section id="forward-type-declarations">
+<h4 id="forward-type-declarations">Forward type declarations</h4>
+<p>TODO(kschimpf)</p>
+</section><section id="select-instruction">
+<h4 id="select-instruction">Select Instruction</h4>
+<p>TODO(kschimpf)</p>
+</section><section id="call-instructions">
+<h4 id="call-instructions">Call Instructions</h4>
+<p>TODO(kschimpf)</p>
+</section></section><section id="intrinsic-functions">
+<h3 id="intrinsic-functions">Intrinsic Functions</h3>
+<p>TODO(kschimpf)</p>
+</section></section><section id="support-functions">
+<h2 id="support-functions">Support Functions</h2>
+<p>Defines functions used to convert syntactic representation to corresponding
+records.</p>
+<section id="signrotate">
+<h3 id="signrotate">SignRotate</h3>
+<p>The SignRotate function encodes a signed integer in an easily compressable
+form. This is done by rotating the sign bit to the rightmost bit, rather than
+the leftmost bit. By doing this rotation, both small positive and negative
+integers are small (unsigned) integers. Therefore, all small integers can be
+encoded as a small (unsigned) integers.</p>
+<p>The definition of SignRotate(N) is:</p>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Argument</th>
+<th class="head">Value</th>
+<th class="head">Condition</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>N</td>
+<td>abs(N)&lt;&lt;1</td>
+<td>N &gt;= 0</td>
+</tr>
+<tr class="row-odd"><td>N</td>
+<td>abs(N)&lt;&lt;1 + 1</td>
+<td>N &lt; 0</td>
+</tr>
+</tbody>
+</table>
+</section><section id="absoluteindex">
+<h3 id="absoluteindex">AbsoluteIndex</h3>
+<p>Bitcode ID&#8217;s of the forms <em>&#64;fN</em>, <em>&#64;gN</em>, <em>%pN</em>, <em>%cN</em>, and <em>%vN</em>, are combined
+into a single index space. This can be done because of the ordering imposed by
+PNaClAsm. All function address bitcode IDs must be defined before any of the
+other forms of bitcode IDs. All global address bitcode IDs must be defined
+before any local bitcode IDs. Within a function block, the parameter bitcode IDs
+must be defined before constant IDs, and constant IDs must be defined before
+instruction value IDs.</p>
+<p>Hence, within a function block, it is safe to refer to all of these
+bitcode IDs using a single <em>absolute</em> index. The abolute index for
+each kind of bitcode ID is computed as follows:</p>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Bitcode ID</th>
+<th class="head">AbsoluteIndex</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>&#64;fN</td>
+<td>N</td>
+</tr>
+<tr class="row-odd"><td>&#64;gN</td>
+<td>N + NumDefinedFcnAddresses</td>
+</tr>
+<tr class="row-even"><td>&#64;pN</td>
+<td>N + NumDefinedFcnAddresses + NumGlobalAddresses</td>
+</tr>
+<tr class="row-odd"><td>&#64;cN</td>
+<td>N + NumDefinedFcnAddresses + NumGlobalAddresses + NumParams</td>
+</tr>
+<tr class="row-even"><td>&#64;vN</td>
+<td>N + NumDefinedFcnAddresses + NumGlobalAddresses + NumParams + NumFcnConsts</td>
+</tr>
+</tbody>
+</table>
+</section><section id="relativeindex">
+<h3 id="relativeindex">RelativeIndex</h3>
+<p>Relative indices are used to refer to values within instructions of a
+function.  The relative index of an ID is always defined in terms of
+the index associated with the next value generating instruction. It is
+defined as follows:</p>
+<pre class="prettyprint">
+RelativeIndex(J) = AbsoluteIndex(NumValuedInsts) - AbsoluteIndex(J)
+</pre>
+</section><section id="abbrevindex">
+<h3 id="abbrevindex">AbbrevIndex</h3>
+<p>This function converts user-defined abbreviation indices to the corresponding
+internal abbreviation index saved in the bitcode file. It adds 4 to its argument,
+since there are 4 predefined internal abbreviation indices (0, 1, 2, and 3).</p>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">N</th>
+<th class="head">AbbrevIndex(N)</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>undefined</td>
+<td>3</td>
+</tr>
+<tr class="row-odd"><td>%aA</td>
+<td>A + 4</td>
+</tr>
+<tr class="row-even"><td>&#64;aA</td>
+<td>A + 4</td>
+</tr>
+</tbody>
+</table>
+</section><section id="log2">
+<h3 id="log2">Log2</h3>
+<p>This is the 32-bit log2 value of its argument.</p>
+</section><section id="exp">
+<h3 id="exp">exp</h3>
+<pre class="prettyprint">
+exp(n, m)
+</pre>
+<p>Denotes the <em>m</em> power of <em>n</em>.</p>
+</section><section id="bitsizeof">
+<h3 id="bitsizeof">BitSizeOf</h3>
+<p>Returns the number of bits needed to represent its argument (a type).</p>
+</section><section id="underlyingtype">
+<h3 id="underlyingtype">UnderlyingType</h3>
+<p>Returns the primitive type of the type construct. For primitive types,
+the <em>UnderlyingType</em> is itself. For vector types, the base type of the
+vector is the underlying type.</p>
+</section><section id="underlyingcount">
+<h3 id="underlyingcount">UnderlyingCount</h3>
+<p>Returns the number of primitive types in the construct. For primitive
+types, the <em>UnderlyingCount</em> is 1. For vector types, it returns the
+number of elements in the vector.</p>
+</section><section id="isinteger">
+<h3 id="isinteger">IsInteger</h3>
+<p>Returns true if the argument is in {i1, i8, i16, i32, i64}.</p>
+</section><section id="isfloat">
+<h3 id="isfloat">IsFloat</h3>
+<p>Returns true if the argument is in {float, double}.</p>
+</section><section id="abbreviations">
+<h3 id="abbreviations">Abbreviations</h3>
+<p>TODO(kschimpf)</p>
+<section id="id4">
+<h4 id="id4">Introduction</h4>
+<p>TODO(kschimpf)</p>
+<ul class="small-gap">
+<li>Blocks</li>
+<li>Data Records</li>
+<li>Abbreviations</li>
+<li>Abbreviation Ids.</li>
+</ul>
+</section><section id="bitstream-format">
+<h4 id="bitstream-format">Bitstream Format</h4>
+<p>TODO(kschimpf)</p>
+<ul class="small-gap">
+<li>Header</li>
+<li>Block Structue</li>
+<li>Primitives</li>
+<li>Abbreviations</li>
+<li>BlockInfoBlock</li>
+</ul>
+</section></section><section id="reference-implementation">
+<h3 id="reference-implementation">Reference Implementation</h3>
+<p>TODO(kschimpf)</p>
+</section></section></section>
+
+{{/partials.standard_nacl_article}}