native_client_sdk/doc_generated/reference/pnacl-bitcode-manual.html - Issue 266713003: Initial draft of PNaCl bitcode files document.

Unified Diff: native_client_sdk/doc_generated/reference/pnacl-bitcode-manual.html

Issue 266713003: Initial draft of PNaCl bitcode files document. (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src

Patch Set: Second version of document. Created 6 years, 7 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View side-by-side diff with in-line comments

Download patch

« no previous file with comments | « chrome/common/extensions/docs/templates/json/chrome_sidenav.json ('k') | native_client_sdk/doc_generated/sitemap.html » ('j') | native_client_sdk/src/doc/reference/pnacl-bitcode-manual.rst » ('J')
Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

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

diff --git a/native_client_sdk/doc_generated/reference/pnacl-bitcode-manual.html b/native_client_sdk/doc_generated/reference/pnacl-bitcode-manual.html

new file mode 100644

index 0000000000000000000000000000000000000000..37f29d5ff4bdf540b05d73b4acee201a1267f5a3

--- /dev/null

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

@@ -0,0 +1,3937 @@

+{{+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><a class="reference internal" href="#parse-state" id="id12">Parse State</a>

+<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><a class="reference internal" href="#special-records" id="id17">Special records</a>

+<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><a class="reference internal" href="#types-block" id="id21">Types Block</a>

+<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><a class="reference internal" href="#globals-block" id="id29">Globals block</a>

+<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><a class="reference internal" href="#module-block" id="id39">Module Block</a>

+<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><a class="reference internal" href="#function-blocks" id="id43">Function Blocks</a>

+<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><a class="reference internal" href="#terminator-instructions" id="id46">Terminator Instructions</a>

+<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><a class="reference internal" href="#integer-binary-inststructions" id="id53">Integer Binary Inststructions</a>

+<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><a class="reference internal" href="#floating-binary-inststructions" id="id67">Floating Binary Inststructions</a>

+<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><a class="reference internal" href="#memory-creation-and-access-instructions" id="id73">Memory creation and access Instructions</a>

+<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><a class="reference internal" href="#conversion-instructions" id="id77">Conversion Instructions</a>

+<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><a class="reference internal" href="#other-instructions" id="id88">Other Instructions</a>

+<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><a class="reference internal" href="#support-functions" id="id94">Support Functions</a>

+<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><a class="reference internal" href="#abbreviations" id="id106">Abbreviations</a>

+<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>

+This document is a reference manual for the contents of PNaCl bitcode files. It

+is presented using assembly language PNaClAsm. PNaClAsm uses a static single

+assignment (SSA) based representation that requires generated results to have a

+single (assignment) source. PNaClAsm is the textual version of the bitcode file.

+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.

+Below PNaClAsm is the high-level form of the data stored in PNaCl bitcode

+files. Each construct in PNaClAsm defines a corresponding PNaCl record [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.

+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 code), and nested structures. The nested structures are defined by

+corresponding enter and exit block records.

+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.

+The PNaCl bitcode writer 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.

+For every kind of record, there is a default method for converting records into

+bit sequences. These methods correspond to a notion of abbreviations

+[ref]. Each abbreviation defines a specific bit sequence conversion to be

+applied. The default conversion methods are simply predefined abbreviations.

+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

+PNaCl bitcode writer 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.

+The PNaCl bitcode reader then uses these abbreviations to convert the bit

+sequences back into the corresponding records.

+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.

+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.

+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.

+</section><section id="data-model">

+<h2 id="data-model">Data Model</h2>

+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 long

+long).

+Integers are assumed to be modeled using two’s complement. Floating point

+support is fixed at IEEE 754 32-bit and 64-bit values (f32 and f64,

+respectively).

+</section><section id="high-level-basics">

+<h2 id="high-level-basics">High Level Basics</h2>

+A program is defined as a sequence of top-level blocks. Blocks can be nested

+within other blocks. Each block defines a sequence of records.

+Most of the records, within a block, also define a unique values. Each unique

+value is given a corresponding unique identifier (i.e. ID). In PNaClAsm. each

+kind of block defines its own kind of identifiers. The names of these

+identifiers are defined by concatenating a prefix character (‘@’ or ‘%’), 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.

+Identifiers are categorized into two types, local and global. 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 PNaCl

+translator uses this separation to parallelize the compilation of functions.

+Global identifiers use the prefix character ‘@’ while local identifiers use

+the prefix character ‘%’.

+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.

+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.

+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.

+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.

+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.

+</section><section id="pnacl-blocks">

+<h2 id="pnacl-blocks">PNaCl Blocks</h2>

+Blocks are used to organize records in the bitcode file. The kinds of blocks

+defined in PNaClAsm are:

+<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>

+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.

+Each block, within a bitcode file, defines values. These values are associated

+with IDs. Each type of block defines different kinds of IDs.

+The abbreviations block [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

+@aN.

+The types block [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 @tN, where N corresponds to the (relative) position

+of the corresponding defining record in the types block.

+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.

+The module block [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.

+Function addresses are global IDs of the form @fN, where N corresponds to

+the position of the corresponding function address record in the module

+block. Function addresses must appear after the types block.

+The globals block [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.

+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 @gN, where N is the (relative) position of the corresponding defining

+records.

+The valuesymtab block [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 intrinsic [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.

+Each function block [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 constants block, nested within the

+corresponding function block.

+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.

+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.

+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 %pN. Basic

+block IDs are identified using local IDs of the form

+%bN. Instructions that generate values are identified using local

+IDs of the form %vN.

+Hence, %pN denotes the Nth parameter of the function. %bN denotes

+the Nth basic block within the function. %vN denotes the value

+generated by the Nth instruction that generates a value. Note: %vN

+does not necessarily refer to the Nth instruction in the function

+block, because not all instructions generate values.

+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 terminating [ref] (e.g. branch) instructions are used to

+determine block boundaries.

+Each constants block [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 %cN, where N corresponds to the (relative) position of the constant

+defined in the corresponding constants block. The constants block must appear

+before any instruction.

+</section><section id="pnacl-records">

+<h2 id="pnacl-records">PNaCl Records</h2>

+A PNaCl record is a non-empty sequence of unsigned, 64-bit, integers. A record

+is identified by the record code, 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.

+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.

+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’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 >= 2**16.

+A PNaCl record is denoted as follows:

+<pre class="prettyprint">

+a: <v0, v1, ... , vN>

+</pre>

+The value v0 is the record code. The remaining values, v1 through vN, 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.

+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.

+Records are converted to bit sequences using an abbreviation. Let a the the index

+identifying the abbreviation that is used to convert the record to a sequence of

+bits. If a user-defined abbreviation %aA (or @aA if global) is specified in

+the syntax, then a = AbbrevIndex(%aA).

+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.

+There are 4 predefined (default) abbreviation indices, used as the default

+abbreviations for PNaCl records. They are:

+<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>

+A block may (in addition), define a list of block specific, user-defined,

+abbreviations (of length U). The number of bits B specified for an enter

+record must be sufficiently large such that

+<pre class="prettyprint">

+2**B >= U + 4

+</pre>

+In addition, the upper limit for B is 32.

+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.

+</section><section id="conventions-for-describing-records">

+<h2 id="conventions-for-describing-records">Conventions for describing records</h2>

+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.

+For each PNaCl construct, we define multiple subsections. The Syntax

+subsection defines a syntax rule for the construct. The Record subsection

+defines the corresponding record associated with the syntax rule. The

+Semantics subsection describes the semantics associated with the record, in

+terms of data within the parse state and the corresponding syntax.

+The Constraints subsection (if present) defines any constraints associated

+with the construct. The Updates subsection (if present) defines how the

+parse state is updated when the construct is parsed. The Examples

+subsection gives one (or more) examples of using the corresponding PNaClAsm

+construct.

+Some semantics subsections use functions to compute values. The meaning of

+functions can be found in Support Functions [ref].

+Within a syntax rule, there may specifications about abbreviations. These

+abbreviation specifications, if allowed, are at the end of the construct, and

+enclosed in < and > 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.

+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.

+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.

+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.

+For example, consider the following syntax rule:

+<pre class="prettyprint">

+%vN = add T O1, O2; <A>

+</pre>

+This rule defines a PNaClAsm add instruction. This construct defines an

+instruction that adds to two values (O1 and O2) to generate instruction

+value %vN. The types of the arguments, and the result, are all of type

+T. Since abbreviation ID A is present, the record is encoded using that

+abbreviation.

+To be concrete, the syntactic rule above defines the structure of the following

+PNaClAsm examples.

+<pre class="prettyprint">

+%v10 = add i32 %v1, %v2; <@a5>

+%v11 = add i32 %v10, %v3;

+</pre>

+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.

+</section><section id="factorial-example">

+<h2 id="factorial-example">Factorial Example</h2>

+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.

+In C, the factorial function can be defined as:

+<pre class="prettyprint">

+int fact(int n) {

+ if (n == 0) return 1;

+ return n * fact(n-1);

+</pre>

+Compiling this into a PEXE file, and dumping out its contents with utility

+pnacl-bcdis, the corresponding output is:

+<pre class="prettyprint">

+ 0:0|<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> |

+ 16:0|1: <65535, 8, 3> |module { // BlockID = 8

+ 24:0| 3: <1, 1> | version 1;

+ 26:5| 1: <65535, 0, 2> | abbreviations { // BlockID = 0

+ 36:0| 0: <65534> | }

+ 40:0| 1: <65535, 17, 4> | types { // BlockID = 17

+ 48:0| 3: <1, 4> | count 4;

+ 50:6| 3: <7, 32> | @t0 = i32;

+ 54:2| 3: <2> | @t1 = void;

+ 56:2| 3: <21, 0, 0, 0> | @t2 = i32 (i32);

+ 60:4| 3: <7, 1> | @t3 = i1;

+ 63:2| 0: <65534> | }

+ 64:0| 3: <8, 2, 0, 0, 0> | define external i32 @f0(i32);

+ 68:7| 1: <65535, 19, 4> | globals { // BlockID = 19

+ 76:0| 3: <5, 0> | count 0;

+ 78:6| 0: <65534> | }

+ 80:0| 1: <65535, 14, 4> | valuesymtab { // BlockID = 14

+ 88:0| 3: <1, 0, 102, 97, 99, | @f0 : "fact";

+ | 116> |

+ 96:6| 0: <65534> | }

+100:0| 1: <65535, 12, 5> | function i32 @f0(i32 %p0) {

+ | | // BlockID = 12

+108:0| 3: <1, 3> | blocks 3;

+110:7| 1: <65535, 11, 4> | constants { // BlockID = 11

+120:0| 3: <1, 0> | i32:

+122:6| 3: <4, 2> | %c0 = i32 1;

+125:4| 3: <4, 0> | %c1 = i32 0;

+128:2| 0: <65534> | }

+ | | %b0:

+132:0| 3: <28, 1, 2, 32> | %v0 = icmp eq i32 %c1, %c0;

+137:1| 3: <11, 1, 2, 1> | br i1 %v0, %b1, %b2;

+ | | %b1:

+141:4| 3: <10, 3> | ret i32 %c0;

+ | | %b2:

+144:3| 3: <2, 4, 3, 1> | %v1 = sub i32 %p0, %c0;

+148:6| 3: <34, 0, 6, 1> | %v2 = call i32 @f0(i32 %p0);

+153:7| 3: <2, 6, 1, 2> | %v2 = mul i32 @f0, %v1;

+158:2| 3: <10, 1> | ret i32 %v2;

+161:1| 0: <65534> | }

+164:0|0: <65534> |}

+</pre>

+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.

+Bit positions are defined by a pair B:N. B is the number of bytes, while N

+is the bit offset within the B+1 byte. Hence, the bit position (in bits) is:

+<pre class="prettyprint">

+B*8 + N

+</pre>

+Hence, the first header 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).

+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, ‘PEXE’. 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.

+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.

+The types block (starting at bit address 40:0), defines 4 types: i1, i32,

+void, and function signature i32(i32).

+Bit address 64:0 declares the factorial function address @f0, and its

+corresponding type signature. Bit address 88:0 associates the name “fact” with

+function address @f0.

+Bit address 100:0 defines the function block that implemnts function “fact”. 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.

+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 “n *

+fact(n-1)”.

+</section><section id="parse-state">

+<h2 id="parse-state">Parse State</h2>

+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.

+<section id="typing">

+<h3 id="typing">Typing</h3>

+Associated with most identifiers is a type. This type defines what type the

+corresponding value has. It is defined by the (initially empty) map

+<pre class="prettyprint">

+TypeOf: ID -> Type

+</pre>

+For each type in the types block [ref], a corresponding inverse map

+<pre class="prettyprint">

+TypeID: Type -> ID

+</pre>

+is maintained to convert syntactic types to the corresponding type ID.

+Note: This document assumes that map TypeID is automatically maintained during

+updates to map TypeOf (when given a type ID). Hence, updates subsections

+will not contain assignments to this map.

+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).

+Function type signatures are maintained using:

+<pre class="prettyprint">

+TypeOfFcn: ID -> Type

+</pre>

+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:

+<pre class="prettyprint">

+DefiningFcnIDs: set(ID)

+</pre>

+</section><section id="id-counters">

+<h3 id="id-counters">ID Counters</h3>

+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:

+<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>

+A number of blocks define expected sizes of constructs. These sizes are recorded

+in the following size variables:

+<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>

+There are four special PNaCl records, each having its own record code. These

+special records are:

+<dl class="docutils">

+<dt>Header</dt>

+<dd>The header record is the first record of a PNaCl bitcode file, and identifies

+the file’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>

+All special records can’t have user-defined abbreviations associated with

+them. The default abbreviation is always used.

+The following subsections define valid special records, other than abbreviation

+records. Abbreviation records are described in the Abbreviations [ref] section.

+<section id="header-record">

+<h3 id="header-record">Header Record</h3>

+The header record must be the first record in the file. It is the only record in

+the bitcode file that doesn’t have a corresponding construct in

+PNaClAsm.

+Syntax

+There is no syntax for header records in PNaClAsm. It is automatically inserted

+by the PNaCl bitcode writer.

+Record

+<pre class="prettyprint">

+<65532, 80, 69, 88, 69, 1, 0, 8, 0, 17, 0, 4, 0, 2, 0, 0, 0>

+</pre>

+Semantics

+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.

+Examples

+There are no examples for the header record, since it is not part of PNaClAsm.

+</section><section id="enter-block-record">

+<h3 id="enter-block-record">Enter Block Record</h3>

+Block records can be top-level, as well as nested in other blocks. Blocks must

+begin with an enter record, and end with an exit record.

+Syntax

+<pre class="prettyprint">

+N {

+</pre>

+Record

+<pre class="prettyprint">

+1: <65535, ID, B>

+</pre>

+Semantics

+Enter block records define the beginning of a block. B, if present, is the

+number of bits needed to represent all possible abbreviation indices used within

+the block. If omitted, B=2 is assumed.

+The block ID value is dependent on the name N. Valid names and corresponding

+BlockID values are defined as follows:

+<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>

+Note: For readability, PNaClAsm allows a more readable form of a function block

+enter record. See function blocks [ref] for more details.

+Examples

+<pre class="prettyprint">

+module {

+ types {

+ count: 0;

+ }

+ globals {

+ count: 0;

+ }

+</pre>

+This example defines a module, types, and globals block. Both the type and the

+globals block appear within the module block.

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 8, 2>

+1: <65535, 17, 2>

+3: <1, 0>

+0: <65534>

+1: <65535, 19, 2>

+3: <5, 0>

+0: <65534>

+</pre>

+</section><section id="exit-block-record">

+<h3 id="exit-block-record">Exit Block Record</h3>

+Block records can be top-level, as well as nested, records. Blocks must begin

+with an enter record, and end with an exit record.

+Syntax

+<pre class="prettyprint">

+</pre>

+Record

+<pre class="prettyprint">

+0: <65534>

+</pre>

+Semantics

+All exit records are identical, no matter what block they are ending. An exit

+record defines the end of the block.

+Examples

+<pre class="prettyprint">

+module {

+ types {

+ count: 0;

+ }

+ globals {

+ count: 0;

+ }

+</pre>

+This example defines a module, types, and globals block. Both the type and the

+globals block appear within the module block.

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 8, 2>

+1: <65535, 17, 2>

+3: <1, 0>

+0: <65534>

+1: <65535, 19, 2>

+3: <5, 0>

+0: <65534>

+</pre>

+</section></section><section id="types-block">

+<h2 id="types-block">Types Block</h2>

+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.

+Each record in the types block defines a type used by the program. Types can be

+broken into the following groups:

+<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’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>

+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.

+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.

+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’t be used in a PNaCl program.

+The first record of a types block must be a count 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.

+To make this more concrete, consider the following example types block:

+<pre class="prettyprint">

+types {

+ count: 4;

+ @t0 = void;

+ @t1 = i32;

+ @t2 = float;

+ @t3 = void (i32, float);

+</pre>

+This example defines a types block that defines four type IDs:

+<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>

+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 @tN can never appear before the

+assignment to identifier @tN-1. Further, if type identifier @tN is assigned,

+it must appear immediately after the assignment to identifier @tN-1.

+<section id="count-record">

+<h3 id="count-record">Count Record</h3>

+The count record 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.

+Syntax

+<pre class="prettyprint">

+count: N; <A>

+</pre>

+Record

+<blockquote>

+<div>AA: <1, N></div></blockquote>

+Semantics

+This construct defines the number of types used by the PNaCl program. N is

+the number of types defined in the types block. It is an error to define more

+(or fewer) types than value N, within the enclosing types block. A is the

+(optional) abbreviation associated with the record.

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+0 == NumTypes

+</pre>

+Updates

+<pre class="prettyprint">

+ExpectedTypes = N;

+</pre>

+Examples

+<pre class="prettyprint">

+types {

+ count: 2;

+ @t0 = float;

+ @t1 = i32;

+</pre>

+This example defines two types. A 32 bit integer and a 32 bit floating types.

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 17, 2>

+3: <1, 2>

+3: <3>

+3: <7, 32>

+0: <65534>

+</pre>

+</section><section id="void-type">

+<h3 id="void-type">Void Type</h3>

+The void type record defines the void type, which corresponds to the type that

+doesn’t define any value, and has no size.

+Syntax

+<pre class="prettyprint">

+@tN = void; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2>

+</pre>

+Semantics

+The void type record defines the type that has no values and has no size. A

+is the (optional) abbreviation associated with the record.

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+N == NumTypes

+NumTypes < ExpectedTypes

+</pre>

+Updates

+<pre class="prettyprint">

+++NumTypes;

+TypeOf(@tN) = void;

+</pre>

+Examples

+<pre class="prettyprint">

+@t0 = void;

+</pre>

+defines the record

+<pre class="prettyprint">

+3: <2>

+</pre>

+</section><section id="integer-types">

+<h3 id="integer-types">Integer Types</h3>

+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.

+It should be noted that in PNaClAsm, all pointers are implemented as 32-bit

+(unsigned) integers. There isn’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).

+Syntax

+<pre class="prettyprint">

+@tN = iB; <A>

+</pre>

+Record

+<blockquote>

+<div>AA: <7, B></div></blockquote>

+Semantics

+An integer type record defines an integral type. B defines the number of bits

+of the integral type. A is the (optional) abbreviation associated with the

+record.

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+N == NumTypes

+NumTypes < ExpectedTypes

+B in {1, 8, 16, 32, 64}

+</pre>

+Updates

+<pre class="prettyprint">

+++NumTypes;

+TypeOf(@tN) = iB;

+</pre>

+Examples

+<pre class="prettyprint">

+@t1 = i32;

+@t2 = i1;

+@t3 = i64;

+</pre>

+defines the records

+<pre class="prettyprint">

+3: <7, 32>

+3: <7, 1>

+3: <7, 64>

+</pre>

+</section><section id="bit-floating-type">

+<h3 id="bit-floating-type">32-Bit Floating Type</h3>

+PNaClAsm allows computation on 32-bit floating values. A floating type record

+defines the 32-bit floating type.

+Syntax

+<pre class="prettyprint">

+@tN = float; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <3>

+</pre>

+Semantics

+A floating type record defines the 32-bit floating type. A is the (optional)

+abbreviation associated with the record.

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A).

+N == NumTypes

+NumTypes < ExpectedTypes

+</pre>

+Updates

+<pre class="prettyprint">

+++NumTypes;

+TypeOf(@tN) = float;

+</pre>

+Examples

+<pre class="prettyprint">

+@t5 = float;

+</pre>

+defines the record

+<pre class="prettyprint">

+3: <3>

+</pre>

+</section><section id="id1">

+<h3 id="id1">64-bit Floating Type</h3>

+PNaClAsm allows computation on 64-bit floating values. A double type record

+defines the 64-bit floating type.

+Syntax

+<pre class="prettyprint">

+@tN = double; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <4>

+</pre>

+Semantics

+A double type record defines the 64-bit floating type. A is the (optional)

+abbreviation associated with the record.

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+N == NumTypes

+NumTypes < ExpectedTypes

+</pre>

+Updates

+<pre class="prettyprint">

+++NumTypes;

+TypeOf(@tN) = double;

+</pre>

+Examples

+<pre class="prettyprint">

+@t3 = double;

+</pre>

+defines the record

+<pre class="prettyprint">

+3: <4>

+</pre>

+</section><section id="vector-types">

+<h3 id="vector-types">Vector Types</h3>

+TODO(kschimpf) <N x T>

+TODO(kschimpf) Define integral and floating vector types.

+</section><section id="function-type">

+<h3 id="function-type">Function Type</h3>

+The function type can be thought of as a function signature. It consists of a

+return type, and a (possibly empty) list of formal parameter types.

+Syntax

+<pre class="prettyprint">

+%tN = RT (T1, ... , TM) <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <21, 0, IRT, IT1, ... , ITM>

+</pre>

+Semantics

+The function type defines the signature of a function. RT is the return type

+of the function, while types T1 through TM are the types of the

+arguments. Indicies to the corresponding type identifiers is stored in the

+corresponding record.

+The return value must either be a primitive type, type void, 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 integral types are not allowed.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+M >= 0

+IRT = AbsoluteIndex(TypeID(RT))

+IT1 = AbsoluteIndex(TypeID(T1))

+...

+ITM = AbsoluteIndex(TypeID(TM))

+N == NumTypes

+NumTypes < ExpectedTypes

+</pre>

+Updates

+<pre class="prettyprint">

+++NumTypes;

+TypeOf(@tN) = RT (T1, ... , TM)

+</pre>

+Examples

+The following example defines two function signatures (@t4 and @t5):

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 17, 2>

+3: <1, 6>

+3: <7, 32>

+3: <7, 64>

+3: <3>

+3: <2>

+3: <21, 3, 0, 2, 1>

+3: <21, 0>

+0: <65534>

+</pre>

+</section></section><section id="globals-block">

+<h2 id="globals-block">Globals block</h2>

+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.

+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.

+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 N, followed by sequence of N simple initializer records.

+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.

+For notational convenience, PNaClAsm begins a compound record with a “{”, and

+inserts a “}” after the last initializer record associated compound record. This

+latter “}” 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.

+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.

+For example, consider the following:

+<pre class="prettyprint">

+globals {

+ count: 2;

+ const @g0 =

+ zerofill 8;

+ var @g1 =

+ initializers 2 {

+ {1, 2, 3, 4},

+ zerofill 2;

+ }

+</pre>

+TODO: Rewrite this: Base example by line number and corresponding record.

+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, “globals {”, is the beginning of the globals block.

+The second record, “count: 2;”, defines the number of global addresses defined

+by the program, i.e. 2.

+The third record, “const @g0 = ”, defines the global constant address @g0.

+The forth record, “zerofill 8;”, defines to initialize the constant with 8

+bytes, all with the value zero. Thus, the size of @g0 is 8 bytes.

+The fifth record, “var @g1 =”, defines the global variable address @g1. The

+sixth record, “initializers 2 ..”, defines that the initial value of @g1 is

+defined by the sequence of bytes defined by the following 2 initializer

+records. The seventh record, “{1, 2, 3, 4}, defines that the first 4 bytes of

+@g1 are initialized with bytes 1, 2, 3, 4. The eighth record, “zerofill 2”;

+initializes bytes 5 and 6 to zero. The size of @g1 is therefore 6 bytes.

+The nine record is the exit block record.

+In other words, the corresponding records are:

+<pre class="prettyprint">

+1: <65535, 19, 2>

+3: <5, 2>

+3: <0, 0, 1>

+3: <2, 8>

+3: <0, 0, 0>

+3: <1, 2>

+3: <3, 1, 2, 3, 4>

+3: <2, 2>

+0: <65534>

+</pre>

+<section id="id2">

+<h3 id="id2">Count Record</h3>

+The count record defines the number of global addresses used by the PNaCl

+program.

+Syntax

+<pre class="prettyprint">

+count: N; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <5, N>

+</pre>

+Semantics

+This record must appear first in the globals block. The count record defines

+the number of global addresses used by the program. A is the (optional)

+abbreviation associated with the record.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+</pre>

+Updates

+<pre class="prettyprint">

+ExpectedGlobals = N;

+ExpectedInitializers = 0;

+</pre>

+</section><section id="global-variable-addressses">

+<h3 id="global-variable-addressses">Global Variable Addressses</h3>

+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.

+Syntax

+<pre class="prettyprint">

+var @gN, align V = <A>

+var @gN = <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <0, VV, 0>

+</pre>

+Semantics

+A global varaible address record defines a global address for a global variable.

+V is the alignment to for the global variable. VVA is the corresponding

+number of bits associated with alignment V (see constraints). The alignment

+V clause can be omitted if V is zero. A is the (optional) abbreviation

+associated with the record.

+It is assumed that the memory, referenced by the global variable address, can be

+both read and written to.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+N = NumGlobalAddresses

+NumGlobalAddresses < ExpectedGlobals

+ExpectedInitializers = 0

+VV = Log2(V+1)

+</pre>

+Updates

+<pre class="prettyprint">

+++NumGlobalAddresses;

+ExpectedInitializers = 1;

+TypeOf(@gN) = i32;

+</pre>

+Examples

+<pre class="prettyprint">

+var @g0 =

+ zerofill 8;

+var @g1 =

+ {1, 2, 3, 4}

+</pre>

+This example defines two global variable addresses, @g0 and @g1. Both use

+memory alignment of 0. @g0 is an 8 byte variable initialized to zero. @g1

+is a 4 byte variable, initialized by the sequence of bytes 1, 2, 3, and 4.

+The corresponding records defined by the example above are:

+<pre class="prettyprint">

+3: <0, 0, 0>

+3: <2, 8>

+3: <0, 0, 0>

+3: <3, 1, 2, 3, 4>

+</pre>

+</section><section id="global-constant-addresses">

+<h3 id="global-constant-addresses">Global Constant Addresses</h3>

+A global constant address record defines an address corresponding to a global

+constant that can’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.

+Syntax

+<pre class="prettyprint">

+const @gN, align V = <A>

+const @gN = <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <0, VV, 1>

+</pre>

+Semantics

+A global constant address record defines a global address for a global constant.

+V is the memory alignment for the global constant. VV is the corresponding

+number of bits associated with alignment V (see constraints). The alignment

+V caluse can be omitted if V is zero. A is the (optional) abbreviation

+associated with the record.

+It is assumed that the memory, referenced by the global constant

+address, is only read, and can’t be written to.

+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.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+N = NumGlobalAddresses

+NumGlobalAddresses < ExpectedGlobals

+ExpectedInitializers = 0

+VV = Log2(V+1)

+</pre>

+Updates

+<pre class="prettyprint">

+++NumGlobalAddresses;

+ExpectedInitializers = 1;

+TypeOf(@gN) = i32;

+</pre>

+Examples

+<pre class="prettyprint">

+const @g0 =

+ zerofill 8;

+var @g1 =

+ {1, 2}

+</pre>

+This example defines two global constants, with global addresses @g0 and

+@g1. @g0 is an 8 byte constant initialized to zero. @g1 is a 2 byte

+variable, initialized by the sequence of bytes 1 and 2.

+The corresponding PNaCl bitcode records are:

+<pre class="prettyprint">

+3: <0, 0, 1>

+3: <2, 8>

+3: <0, 0, 1>

+3: <3, 1, 2>

+</pre>

+</section><section id="zerofill-initializer">

+<h3 id="zerofill-initializer">Zerofill Initializer</h3>

+The zerofill initializer record intializes a sequence of bytes, associated with

+a global address, with zeros.

+Syntax

+<pre class="prettyprint">

+zerofill N; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, N>

+</pre>

+Semantics

+A zerofill initializer record intializes a sequence of bytes, associated with a

+global address, with zeros. A is the (optional) abbreviation of the associated

+record.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+ExpectedInitializers > 0;

+</pre>

+Updates

+<pre class="prettyprint">

+--ExpectedInitializers;

+</pre>

+Examples

+<pre class="prettyprint">

+const @g0 =

+ zerofill 8;

+var @g1 =

+ zerofill 4;

+</pre>

+This example defines two global constants, with global addresses @g0 and

+@g1. The global memory associated with address @g0, is an eight byte value,

+initialized to zero. The global memory associated with address @g1, is a 4

+byte value, initialized to zero.

+The corresponding PNaCl records are:

+<pre class="prettyprint">

+3: <0, 0, 1>

+3: <2, 8>

+3: <0, 0, 1>

+3: <2, 4>

+</pre>

+</section><section id="data-initializer">

+<h3 id="data-initializer">Data Initializer</h3>

+Data records define a sequence of bytes. These bytes define the initial value of

+the contents of the corresponding memory.

+Syntax

+<pre class="prettyprint">

+{ B1 , .... , BN } <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <3, B1, ..., BN>

+</pre>

+Semantics

+A data record defines a sequence of bytes B1 throught BN, that intialize N

+bytes of memory. A is the (optional) abbreviation associated with the

+record.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+ExpectedInitializers > 0

+</pre>

+Updates

+<pre class="prettyprint">

+--ExpectedInitializers;

+</pre>

+Examples

+<pre class="prettyprint">

+const @g0 =

+ {1, 2, 97, 36, 44, 88, 44}

+const @g1 =

+ initializers 3 {

+ {4, 5, 6, 7}

+ reloc @f1;

+ {99, 66, 22, 12}

+ }

+</pre>

+The corresponding PNaCl records are:

+<pre class="prettyprint">

+3: <0, 0, 1>

+3: <3, 1, 2, 97, 36, 44, 88, 44>

+3: <0, 0, 1>

+3: <1, 3>

+3: <3, 4, 5, 6, 7>

+3: <4, 1>

+3: <3, 99, 66, 22, 12>

+</pre>

+</section><section id="relocation-initializer">

+<h3 id="relocation-initializer">Relocation Initializer</h3>

+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.

+Syntax

+<pre class="prettyprint">

+reloc V; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <4, VV>

+</pre>

+Semantics

+A relocation initializer record defines a 4-byte value containing the specified

+global address V. A is the (optional) abbreviation associated with the

+record.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+VV = AbsoluteIndex(V);

+ExpectedInitializers > 0

+</pre>

+Updates

+<pre class="prettyprint">

+--ExpectedInitializers;

+</pre>

+Examples

+<pre class="prettyprint">

+var @g0 =

+ initializers 3 {

+ reloc @f1;

+ reloc @g0;

+ reloc @g10;

+ }

+</pre>

+This example defines global address @g0. It defines 12 bytes of memory, and is

+initialized with three addresses @f1, @g0, and @g10. Note that all globals

+can be used in a relocation initialization record, even if it isn’t defined yet.

+Assuming

+<pre class="prettyprint">

+100 = AbsoluteIndex(@g0))

+</pre>

+The corresponding PNaCl bitcode records are:

+<pre class="prettyprint">

+3: <0, 0, 0>

+3: <1, 3>

+3: <4, 1>

+3: <4, 100>

+3: <4, 110>

+</pre>

+</section><section id="subfield-relocation-initializer">

+<h3 id="subfield-relocation-initializer">Subfield Relocation Initializer</h3>

+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.

+Syntax

+<pre class="prettyprint">

+reloc V + O; <A>

+reloc V - O; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <4, VV, OOO>

+</pre>

+Semantics

+A relocation initializer record defines a 4-byte value containing the specified

+global (non-funciton) address V, modified by the unsigned offset O. OO is

+the corresponding signed offset. In the first form, OO == O. In the second

+form, OO == - O. A is the (optional) abbreviation associated with the

+record. a is the corresponding abbreviation index of A. When A is omitted,

+a=3.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+VV == AbsoluteIndex(V)

+ExpectedInitializers > 0

+OOO == SignRotate(OO)

+</pre>

+Updates

+<pre class="prettyprint">

+--ExpectedInitializers;

+</pre>

+Examples

+<pre class="prettyprint">

+var @g0 =

+ initializers 3 {

+ reloc @f1;

+ reloc @g0 + 4;

+ reloc @g10 - 3;

+ }

+</pre>

+This example defines global address @g0, and is initialized with three

+pointers, addresses @f1, @g0+4, and @g10-3. Note that all global addresses

+can be used in a relocation initialization record, even if it isn’t defined

+yet. Validity of the reference can be verified, since a global address @g10

+must be smaller than the value specified in the globals count record.

+Assuming

+<pre class="prettyprint">

+100 = AbsoluteIndex(@g0))

+</pre>

+The corresponding PNaCl bitcode records are:

+<pre class="prettyprint">

+3: <0, 0, 0>

+3: <1, 3>

+3: <4, 1>

+3: <4, 100, 8>

+3: <4, 110, 7>

+</pre>

+</section><section id="compound-initializer">

+<h3 id="compound-initializer">Compound Initializer</h3>

+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.

+Syntax

+<pre class="prettyprint">

+initializers N { <A>

+ ...

+</pre>

+Record

+<pre class="prettyprint">

+AA: <1, N>

+</pre>

+Semantics

+Defines that the next N initializers should be associated with the global

+address of the previous record. A is the (optional) abbreviation index

+associated with the record.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+ExpectedInitializers == 1

+</pre>

+Updates

+<pre class="prettyprint">

+ExpectedInitializers = N;

+</pre>

+Examples

+<pre class="prettyprint">

+const @g1 =

+ initializers 3 {

+ {4, 5, 6, 7}

+ reloc @f1;

+ {99, 66, 22, 12}

+ }

+</pre>

+The corresponding PNaCl records are:

+<pre class="prettyprint">

+3: <0, 0, 1>

+3: <1, 3>

+3: <3, 4, 5, 6, 7>

+3: <4, 1>

+3: <3, 99, 66, 22, 12>

+</pre>

+</section></section><section id="valuesymtab-block">

+<h2 id="valuesymtab-block">Valuesymtab Block</h2>

+TODO(kschimpf)

+</section><section id="module-block">

+<h2 id="module-block">Module Block</h2>

+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):

+<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>

+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.

+<section id="version">

+<h3 id="version">Version</h3>

+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.

+Note that currently, only PNaCl bitcode version 2, and version record value 1 is

+defined.

+Syntax

+<pre class="prettyprint">

+version N; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <1, N>

+</pre>

+Semantics

+The version record defines which PNaCl reader/writer rules should be

+followed. N is the version number. Currently N must be 1. Future versions of

+PNaCl may define additional legal values. A is the (optional) abbreviation

+index associated with the record.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+</pre>

+Examples

+<pre class="prettyprint">

+version 1;

+</pre>

+The corresponding record is:

+<pre class="prettyprint">

+3: <1, 1>

+</pre>

+</section><section id="function-address">

+<h3 id="function-address">Function Address</h3>

+A function address record defines a function address. Defining function

+addresses can also imply a corresponding implementation. Defined function

+addresses define implementations while declared function addresses do not.

+The implementation of a defined 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 Nth defining function address record, in the module

+block, has its implementation in the Nth function block of that module block.

+Syntax

+<pre class="prettyprint">

+PN LN T0 @fN ( T1 , ... , TM ); <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <8, T, C, P, L>

+</pre>

+Semnatics

+Defines the function address @fN. PN is the name that specifies

+the prototype value P associated with the function. A function

+address is defining only if P==0. Otherwise, it is only declared.

+The type of the function is defined by function type @tT. L

+is the linkage specification corresponding to name LN. C is the

+calling convention used by the function. A is the

+(optional) abbreviation associated with the record.

+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 void, 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.

+Valid prototype names PN, and corresponding P values, are:

+<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>

+Valid linkage names LN, and corresponding L values, are:

+<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>

+Currently, only one calling convention C is supported:

+<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>

+Constraint

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+T = TypeID(TypeOf(T0 ( T1 , ... , TN )))

+N = NumFuncAddresses

+</pre>

+Updates

+<pre class="prettyprint">

+++NumFuncAddresses;

+TypeOf(@fN) = TypeOf(TypeID(i32));

+TypeOfFcn(@fN) = TypeOf(@tT);

+if PN == 0:

+ DefiningFcnIDs += @FN;

+ ++NumDefinedFunctionAddresses;

+</pre>

+Examples

+<pre class="prettyprint">

+module {

+ ...

+ types {

+ @t0 = void;

+ @t1 = i32;

+ @t3 = float;

+ @t4 = void (i32, float);

+ @t5 = i32 ();

+ }

+ ...

+ declare external void @f0(i32, float);

+ define internal i32 @f1();

+</pre>

+This defines function addresses @f0 and @f1. Function address @f0 is

+defined externally while @f1 has an implementation (defined by a corresponding

+function block). The type signature of @f0 is defined by type @t4 while the

+type signature of @f1 is @t5.

+The corresopnding records for these two function addresses are:

+<pre class="prettyprint">

+3: <8, 4, 0, 1, 0>

+3: <8, 5, 0, 0, 1>

+</pre>

+</section></section><section id="constants-blocks">

+<h2 id="constants-blocks">Constants Blocks</h2>

+TODO(kschimpf)

+</section><section id="function-blocks">

+<h2 id="function-blocks">Function Blocks</h2>

+A function block defines the implementation of a defined function address. The

+function address it defines is based on the position of the corresponding

+defined function address. The Nth defined function address always

+corresponds to the Nth function block in the module block.

+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

+terminator [ref] (branch) instruction.

+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 terminator instructions. The

+instruction that follows a temrinator instruction begins a new basic block.

+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’t be any branches to the entry block of a

+function). Because the entry block has no predecessors, it also can’t have any

+PHI nodes [ref].

+The parameters are implied by the type of the corresponding function

+address. One parameter is defined for each argument of the function type

+signature.

+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 %bN, where N corresponds to the

+position of the basic block within the function block.

+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.

+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.

+Operands are typically defined using an absolute index [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.

+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.

+The following subsections define records that can appear in a function block.

+<section id="function-enter">

+<h3 id="function-enter">Function enter</h3>

+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.

+Syntax

+<pre class="prettyprint">

+function TR @fN ( T0 %p0, ... , TM %pM) {

+</pre>

+Record

+<blockquote>

+<div>1: <65535, 12, B></div></blockquote>

+Semantics

+B is the number of bits reserved for abbreviations in the block. See

+enter block records [ref] for more details.

+The value of N corresponds the the positional index of the corresponding

+defining function address this block is associated with. M is the number of

+defined paramaters (minus one) in the function heading.

+Constraints

+<pre class="prettyprint">

+N == NumFcnImpls

+@fN in DefiningFcnIDs

+TypeOfFcn(@fN) == TypeOf(TypeID(TR (T0, ... , TM)))

+</pre>

+Updates

+<pre class="prettyprint">

+++NumFcnImpls;

+EnclosingFcnID = @fN;

+NumBasicBlocks = 0;

+ExpectedBlocks = 0;

+NumParams = M;

+for I in [0..M]:

+ TypeOf(%pI) = TypeOf(TypeID(TI));

+</pre>

+Examples

+<pre class="prettyprint">

+types {

+ ...

+ @t10 = void (i32, float);

+ ...

+...

+define internal void @f12(i32, float);

+...

+function void @f12(i32 %p0, float %p1) {

+...

+</pre>

+defines the enter block record:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+</pre>

+</section><section id="id3">

+<h3 id="id3">Count Record</h3>

+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.

+Syntax

+<pre class="prettyprint">

+ blocks: N; <A>

+%b0:

+</pre>

+Record

+<pre class="prettyprint">

+AA: <1, N>

+</pre>

+Semantics

+The count record defines the number N of basic blocks in the implemented

+function. A is the (optional) abbreviation associated with the record.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+ExpectedBasicBlocks = 0

+NumBasicBlocks = 0

+</pre>

+Updates

+<pre class="prettyprint">

+ExpectedBlocks = N;

+</pre>

+Examples

+<pre class="prettyprint">

+blocks: 5

+</pre>

+The corresponding PNaCl bitcode record is:

+<pre class="prettyprint">

+3: <1, 5>

+</pre>

+</section><section id="terminator-instructions">

+<h3 id="terminator-instructions">Terminator Instructions</h3>

+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.

+<section id="return-void-instruction">

+<h4 id="return-void-instruction">Return Void Instruction</h4>

+The return void instruction is used to return control from a function back to

+the caller, without returning any value.

+Syntax

+<pre class="prettyprint">

+ ret; <A>

+%bB:

+</pre>

+Record

+<pre class="prettyprint">

+AA: <10>

+</pre>

+Semantics

+The return instruction returns control to the calling function.

+B is the number associated with the next basic block. Label %bB: only

+appears if B < ExpectedBasicBlocks. That is, the label is omitted only if this

+terminator instruction is the last instruction in the function block. A is

+the (optional) abbreviation index associated with the record.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+B == NumBasicBlocks + 1

+NumBasicBlocks < ExpectedBasicBLocks

+ReturnType(TypeOf(EnclosingFcnID)) == void

+</pre>

+Updates

+<pre class="prettyprint">

+++NumBasicBlocks;

+</pre>

+Examples

+The following shows the implementation of a function that simply returns.

+<pre class="prettyprint">

+function void @f5() {

+ blocks: 1;

+%b0:

+ ret;

+</pre>

+The corresponding PNaCl records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <10>

+0: <65534>

+</pre>

+</section><section id="return-value-instruction">

+<h4 id="return-value-instruction">Return Value Instruction</h4>

+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.

+Syntax

+<pre class="prettyprint">

+ ret T V; <A>

+%bB:

+</pre>

+Record

+<pre class="prettyprint">

+AA: <10, VV>

+</pre>

+Semantics

+The return instruction returns control to the calling function, returning the

+provided value.

+V is the value to return. Type T must be of the type returned by the

+function. It must also be the type associated with value V. A is the

+(optional) abbreviation index associated with the record.

+B is the number associated with the next basic block. Label %bB: only

+appears if B < ExpectedBasicBlocks. That is, the label is omitted only if this

+terminator instruction is the last instruction in the function block.

+The return type T 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.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+VV = RelativeIndex(V)

+B = NumBasicBlocks + 1

+NumBasicBlocks < ExpectedBasicBlocks

+T = TypeOf(V) = ReturnType(TypeOf(EnclosingFcnID))

+</pre>

+Updates

+<pre class="prettyprint">

+++NumBasicBlocks;

+</pre>

+Examples

+The following shows a return statement that returns the value generated by the

+previous instruction:

+<pre class="prettyprint">

+function i32 @f5(i32 %p0) {

+ blocks: 1;

+@b0:

+ ret i32 @p0;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="unconditional-branch-instruction">

+<h4 id="unconditional-branch-instruction">Unconditional Branch Instruction</h4>

+The unconditional branch instruction is used to cause control flow to transfer

+to a different basic block of the function.

+Syntax

+<pre class="prettyprint">

+ br %bN; <A>

+%bB:

+</pre>

+Record

+<pre class="prettyprint">

+AA: <11, N>

+</pre>

+Semantics

+The unconditional branch instruction causes control flow to transfer to basic

+block N. A is the (optional) abbreviation index associated with the record.

+B is the number associated with the next basic block. Label %bB: only

+appears if B < ExpectedBasicBlocks. That is, the label is omitted only if this

+terminator instruction is the last instruction in the function block.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+0 < N

+N < ExpectedBasicBlocks

+B = NumBasicBlocks + 1

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumBasicBlocks;

+</pre>

+Examples

+<pre class="prettyprint">

+br %b2;

+</pre>

+This branch instruction branches to the 3rd basic block of the function. It

+defines the following PNaCL record:

+<pre class="prettyprint">

+3: <11, 2>

+</pre>

+</section><section id="conditional-branch-instruction">

+<h4 id="conditional-branch-instruction">Conditional Branch Instruction</h4>

+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.

+Syntax

+<pre class="prettyprint">

+ br i1 C, %bT, %bBF; <A>

+%bB:

+</pre>

+Record

+<pre class="prettyprint">

+AA: <11, T, F, V>

+</pre>

+Semantics

+Upon execution of a conditional branch instruction, the i1 (boolean) argument

+C is evaluated. If the value is true, control flows to basic block

+%bT. Otherwise control flows to basic block %bF. A is the (optional)

+abbreviation index associated with the record.

+B is the number associated with the next basic block. Label %bB: only

+appears if B < ExpectedBasicBlocks. That is, the label is omitted only if this

+terminator instruction is the last instruction in the function block.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+V = RelativeIndex(C)

+0 < T

+B1 < ExpectedBasicBlocks

+0 < F

+B2 < ExpectedBasicBlocks

+B = NumBasicBlocks + 1

+NumBasicBlocks < ExpectedBasicBlocks

+TypeOf(C) == i1

+</pre>

+Updates

+<pre class="prettyprint">

+++NumBasicBlocks;

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @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>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 3>

+3: <28, 2, 1, 32>

+3: <11, 2, 1, 1>

+3: <10, 3>

+3: <10, 2>

+0: <65534>

+</pre>

+</section><section id="unreachable">

+<h4 id="unreachable">Unreachable</h4>

+The unreachable instruction has no defined semantics. The instruction is used to

+inform the PNaCl translator that control can’t reach this instruction.

+Syntax

+<pre class="prettyprint">

+ unreachable; <A>

+%bB:

+</pre>

+Record

+<pre class="prettyprint">

+AA: <15>

+</pre>

+Semantics

+Directive to the PNaCl translator that this instruction is unreachable. A

+is the (optional) abbreviation index associated with the record.

+B is the number associated with the next basic block. Label %bB: only

+appears if B < ExpectedBasicBlocks. That is, the label is omitted only if this

+terminator instruction is the last instruction in the function block.

+Constraints

+<pre class="prettyprint">

+AA = AbbrevIndex(A)

+B = NumBasicBlocks + 1

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumBasicBlocks;

+</pre>

+Examples

+TODO(kschimpf)

+</section><section id="switch-instruction">

+<h4 id="switch-instruction">Switch Instruction</h4>

+TODO(kschimpf)

+</section></section><section id="integer-binary-inststructions">

+<h3 id="integer-binary-inststructions">Integer Binary Inststructions</h3>

+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.

+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.

+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.

+For most binary operations (except some of the logical operations), integral

+type i1 is disallowed.

+<section id="integer-add">

+<h4 id="integer-add">Integer Add</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = add T V1, V2; <A>

+</pre>

+Record

+<blockquote>

+<div>AA: <2, VV1, VV2, 0></div></blockquote>

+Semantics

+The integer add instruction returns the sum of its two arguments. Arguments V1 and

+V2, and the result %vN, must be of type T. T must be an integral type,

+or an integral vector type. N is defined by the record position, defining the

+corresponding value generated by the instruction. A is the (optional)

+abbreviation associated with the corresponding record.

+Overflow conditions are ignored, and the result returned is the mathematical

+result modulo exp(2,n), where n is the bitwidth of the integer result.

+Because integers are assumed to use a two’s complement representation,

+this instruction is appropriate for both signed and unsigned integers.

+In the add instruction, Integral type i1 (and vectors on integral type i1) is

+disallowed.

+Constraints

+<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 < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @f0(i32 %p0, i32 %p1) {

+ blocks: 1;

+%b0:

+ %v0 = add i32 %p0, %p1;

+ %v1 = add i32 %p0, %v0;

+ ret i32 %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 0>

+3: <2, 3, 1, 0>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="integer-subtract">

+<h4 id="integer-subtract">Integer Subtract</h4>

+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.

+Note: Since there isn’t a negate instruction, subtraction from constant zero

+should be used to negate values.

+Syntax

+<pre class="prettyprint">

+%vN = sub T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 1>

+</pre>

+Semantics

+The integer subtract returns the difference of its two arguments. Arguments V1

+and V2, and the result %vN must be of type T. T must be an integral

+type, or an integral vector type. N is defined by the record position, defining

+the corresponding value generated by the instruction. A is the (optional)

+abbreviation ¯associated with the corresponding record.

+Underflow conditions are ignored, and the result returned is the mathematical

+result modulo exp(2, n), where n is the integer bitwidth of the result.

+Because integers are assumed to use a two’s complement representation,

+this instruction is appropriate for both signed and unsigned integers.

+In the subtract instruction, Integral type i1 is disallowed.

+Constraints

+<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 < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @f0(i32 %p0, i32 %p1) {

+ blocks: 1;

+%b0:

+ %v0 = sub i32 %p0, %p1;

+ %v1 = sub i32 %p0, %v0;

+ ret i32 %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 1>

+3: <2, 3, 1, 1>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="integer-multiply">

+<h4 id="integer-multiply">Integer Multiply</h4>

+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.

+Syntax

+<pre class="prettyprint">

+&vN = mul T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 2>

+</pre>

+Semantics

+The intebger multiply instruction returns the product of its two

+arguments. Arguments V1 and V2, and the result %vN, must be of type T.

+T must be an integral type, or an integral vector type. N is defined by the

+record position, defining the corresponding value generated by the

+instruction. A is the (optional) abbreviation associated with the

+corresponding record.

+Overflow conditions are ignored, and the result returned is the mathematical

+result modulo exp(2, n), where n is the bitwidth of the result.

+Because integers are assumed to use a two’s complement representation,

+this instruction is appropriate for both signed and unsigned integers.

+In the subtract instruction, Integral type i1 is disallowed.

+Constraints

+<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 < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @f0(i32 %p0, i32 %p1) {

+ blocks: 1;

+%b0:

+ %v0 = mul i32 %p0, %p1;

+ %v1 = mul i32 %v0, %p1;

+ ret i32 %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 2>

+3: <2, 1, 2, 2>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="signed-integer-divide">

+<h4 id="signed-integer-divide">Signed Integer Divide</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = sdiv T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 4>

+</pre>

+Semantics

+The divide instruction returns the quotient of its two arguments. Arguments V1

+and V2, and the result %vN, must be of type T. T must be a integral

+type, or an integral vector type. N is defined by the record position,

+defining the corresponding value generated by the instruction. A is the

+(optional) abbreviation associated with the corresponding record.

+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).

+In the signed integer divide instruction, integral type i1 is

+disallowed. Integer division by zero is guaranteed to trap. Overflow is also

+undefined.

+Constraints

+<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 < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @f0(i32 %p0, i32 %p1) {

+ blocks: 1;

+%b0:

+ %v0 = sdiv i32 %p0, %p1;

+ %v1 = sdiv i32 %v0, %p1;

+ ret i32 %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 4>

+3: <2, 1, 2, 4>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="unsigned-integer-divide">

+<h4 id="unsigned-integer-divide">Unsigned Integer Divide</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = udiv T V1, V2; <a>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, A1, A2, 3>

+</pre>

+Semantics

+The unsigned integer divide instruction returns the quotient of its two

+arguments. Arguments V1 and V2, and the result %vN, must be of type

+T. T must be an integral type, or an integral vector type. N is defined

+by the record position, defining the corresponding value generated by the

+instruction. A is the (optional) abbreviation associated with the

+corresponding record.

+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).

+In the unsigned integer divide instruction, Integral type i1 is

+disallowed. Division by zero is guaranteed to trap. Overflow is also undefined.

+Constraints

+<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 < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @f0(i32 %p0, i32 %p1) {

+ blocks: 1;

+%b0:

+ %v0 = udiv i32 %p0, %p1;

+ %v1 = udiv i32 %v0, %p1;

+ ret i32 %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 3>

+3: <2, 1, 2, 3>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="signed-integer-remainder">

+<h4 id="signed-integer-remainder">Signed Integer Remainder</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = srem T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 6>

+</pre>

+Semantics

+The signed integer remainder instruction returns the remainder of the quotient

+of its two arguments. Arguments V1 and V2, and the result %vN, must be of

+type T. T must be a integral type, or an integral vector type. N is

+defined by the record position, defining the corresponding value generated by

+the instruction. A is the (optional) abbreviation associated with the

+corresponding record.

+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).

+In the signed integer remainder instruction, Integral type i1 is disallowed.

+Division by zero is guaranteed to trap. Overflow is also undefined.

+Constraints

+<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 < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @f0(i32 %p0, i32 %p1) {

+ blocks: 1;

+%b0:

+ %v0 = srem i32 %p0, %p1;

+ %v1 = srem i32 %v0, %p1;

+ ret i32 %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 6>

+3: <2, 1, 2, 6>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="unsigned-integer-remainder-instruction">

+<h4 id="unsigned-integer-remainder-instruction">Unsigned Integer Remainder Instruction</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = urem T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, A1, A2, 5>

+</pre>

+Semantics

+The unsigned integer remainder instruction returns the remainder of the quotient

+of its two arguments. Arguments V1 and V2, and the result %vN, must be of

+type T. T must be an integral type, or an integral vector type. N is

+defined by the record position, defining the corresponding value generated by

+the instruction. A is the (optional) abbreviation associated with the

+corresponding record.

+Unsigned values are assumed. Note that signed and unsigned integer division are

+distinct operations. For signed integer division use the remainder instruction

+(srem).

+In the unsigned integer remainder instruction, Integral type i1 is disallowed.

+Division by zero is guaranteed to trap. Overflow is also undefined.

+Constraints

+<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 < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @f0(i32 %p0, i32 %p1) {

+ blocks: 1;

+%b0:

+ %v0 = srem i32 %p0, %p1;

+ %v1 = srem i32 %v0, %p1;

+ ret i32 %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 5>

+3: <2, 1, 2, 5>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="shift-left">

+<h4 id="shift-left">Shift left</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = shl T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 7>

+</pre>

+Semantics

+This instruction performs a shift left operation. Argument V1 and the result

+%vN must be of type T. T nust be an integral, or a vector of

+integrals. V2 must be an integral type. N is defined by the record position,

+defining the corresponding value generated by the instruction. A is the

+(optional) abbreviation associated with the corresponding record.

+V2 is assumed to be unsigned. The least significant bits of the result will

+be filled with zero bits after the shift. If V2 is (statically or dynamically)

+is negative or equal to or larger than the number of bits in V1, the result is

+undefined. If the arguments are vectors, each vector element of V1 is shifted

+by the corresponding shift amount in V2.

+In the shift left instruction, Integral type i1 is disallowed for either

+argument.

+Constraints

+<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 < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @f0(i32 %p0, i32 %p1) {

+ blocks: 1;

+%b0:

+ %v0 = shl i32 %p0, %p1;

+ %v1 = shl i32 %v0, %p1;

+ ret i32 %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 7>

+3: <2, 1, 2, 7>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="logical-shift-right">

+<h4 id="logical-shift-right">Logical Shift right</h4>

+The logical shift right instruction returns the first operand, shifted

+to the right a specified number of bits with zero fill.

+Syntax

+<pre class="prettyprint">

+%vN = lshr T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 8>

+</pre>

+Semantics

+This instruction performs a logical shift right operation. Arguments V1 and

+the result %vN must be of type T. T nust be an integral, or a vector of

+integrals. V2 must be an integral type. N is defined by the record position,

+defining the corresponding value generated by the instruction. A is the

+(optional) abbreviation associated with the corresponding record.

+V2 is assumed to be unsigned. The most significant bits of the result will be

+filled with zero bits after the shift. If V2 is (statically or dynamically)

+negative or equal to or larger than the number of bits in V1, the result is

+undefined. If the arguments are vectors, each vector element of V1 is shifted

+by the corresponding shift amount in V2.

+In the logical shift right instruction, Integral type i1 is disallowed for

+either argument.

+Constraints

+<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 < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @f0(i32 %p0, i32 %p1) {

+ blocks: 1;

+%b0:

+ %v0 = lshr i32 %p0, %p1;

+ %v1 = lshr i32 %v0, %p1;

+ ret i32 %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 8>

+3: <2, 1, 2, 8>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="arithmetic-shift-right">

+<h4 id="arithmetic-shift-right">Arithmetic Shift Right</h4>

+The arithmetic shift right instruction returns the first operand,

+shifted to the right a specified number of bits with sign extension.

+Syntax

+<pre class="prettyprint">

+%vN = ashr T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, VV1, VVA2, 9>

+</pre>

+Semantics

+This instruction performs an arithmetic shift right operation. Arguments V1

+and the result %vN must be of type T. T nust be an integral, or a vector

+of integrals. V2 must be an integral type. N is defined by the record

+position, defining the corresponding value generated by the instruction. A is

+the (optional) abbreviation associated with the corresponding record.

+V2 is assumed to be unsigned. The most significant bits of the result will be

+filled with the sign bit of V1. If V2 is (statically or dynamically)

+negative or equal to or larger than the number of bits in V1, the result is

+undefined. If the arguments are vectors, each vector element of V1 is shifted

+by the corresponding shift amount in V2.

+In the arithmetic shift right instruction, integral type i1 is disallowed for

+either argument.

+Constraints

+<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 < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @f0(i32 %p0, i32 %p1) {

+ blocks: 1;

+%b0:

+ %v0 = ashr i32 %p0, %p1;

+ %v1 = ashr i32 %v0, %p1;

+ ret i32 %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 9>

+3: <2, 1, 2, 9>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="logical-and">

+<h4 id="logical-and">Logical And</h4>

+The and instruction returns the bitwise logical and of its two operands.

+Syntax

+<pre class="prettyprint">

+%vN = and T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 10>

+</pre>

+Semantics

+This instruction performs a bitwise logical and of its arguments. Arguments

+V1 and V2, and the result %vN must be of type T. T nust be an

+integral, or a vector of integrals. N is defined by the record position,

+defining the corresponding value generated by the instruction. A is the

+(optional) abbreviation associated with the corresponding record.

+The truth table used for the and instruction is:

+<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>

+</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>

+</tr>

+<tr class="row-odd"><td>1</td>

+<td>1</td>

+</tr>

+</tbody>

+</table>

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+VV1 == RelativeIndex(V1)

+VV2 == RelativeIndex(V2)

+T == TypeOf(V1) == TypeOf(V2)

+IsInteger(UnderlyingType(T)))

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @f0(i32 %p0, i32 %p1) {

+ blocks: 1;

+%b0:

+ %v0 = and i32 %p0, %p1;

+ %v1 = and i32 %v0, %p1;

+ ret i32 %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 10>

+3: <2, 1, 2, 10>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="logical-or">

+<h4 id="logical-or">Logical Or</h4>

+The or instruction returns the bitwise logical inclusive or of its

+two operands.

+Syntax

+<pre class="prettyprint">

+%vN = or T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 11>

+</pre>

+Semantics

+This instruction performs a bitwise logical inclusive or of its arguments.

+Arguments V1 and V2, and the result %vN must be of type T. T nust be

+an integral, or a vector of integrals. N is defined by the record position,

+defining the corresponding value generated by the instruction. A is the

+(optional) abbreviation associated with the corresponding record.

+The truth table used for the or instruction is:

+<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>

+</tr>

+<tr class="row-odd"><td>0</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>

+</tr>

+</tbody>

+</table>

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+VV1 == RelativeIndex(V1)

+VV2 == RelativeIndex(V2)

+T == TypeOf(V1) == TypeOf(V2)

+IsInteger(UnderlyingType(T)))

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @f0(i32 %p0, i32 %p1) {

+ blocks: 1;

+%b0:

+ %v0 = or i32 %p0, %p1;

+ %v1 = or i32 %v0, %p1;

+ ret i32 %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 11>

+3: <2, 1, 2, 11>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="logical-xor">

+<h4 id="logical-xor">Logical Xor</h4>

+The xor instruction returns the bitwise logical exclusive or of its

+two operands.

+Syntax

+<pre class="prettyprint">

+%vN = xor T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 12>

+</pre>

+Semantics

+This instruction performs a bitwise logical exclusive or of its

+arguments. Arguments V1 and V2, and the result %vN must be of

+type T. T nust be an integral, or a vector of integrals. N is

+defined by the record position, defining the corresponding value

+generated by the instruction. A is the (optional) abbreviation

+associated with the corresponding record.

+The truth table used for the or instruction is:

+<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>

+</tr>

+<tr class="row-odd"><td>0</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>

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+A1 == RelativeIndex(V1)

+A2 == RelativeIndex(V2)

+T == TypeOf(V1) == TypeOf(V2)

+IsInteger(UnderlyingType(T)))

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function i32 @f0(i32 %p0, i32 %p1) {

+ blocks: 1;

+%b0:

+ %v0 = xor i32 %p0, %p1;

+ %v1 = xor i32 %v0, %p1;

+ ret i32 %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 12>

+3: <2, 1, 2, 12>

+3: <10, 1>

+0: <65534>

+</pre>

+</section></section><section id="floating-binary-inststructions">

+<h3 id="floating-binary-inststructions">Floating Binary Inststructions</h3>

+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.

+<section id="float-add">

+<h4 id="float-add">Float Add</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = add T V1, V2; <A>

+</pre>

+Record

+<blockquote>

+<div>AA: <2, VV1, VV2, 0></div></blockquote>

+Semantics

+The float add instruction returns the sum of its two arguments. Arguments V1

+and V2 and the result %vN must be of type T. T must be a floating type,

+or a floating vector type. N is defined by the record position, defining the

+corresponding value generated by the instruction. A is the (optional)

+abbreviation associated with the corresponding record.

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+VV1 == RelativeIndex(V1)

+VV2 == RelativeIndex(V2)

+T == TypeOf(V1) == TypeOf(V2)

+IsFloat(UnderlyingType(T))

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function float @f0(float %p0, float %p1) {

+ blocks: 1;

+%b0:

+ %v0 = add float %p0, %p1;

+ %v1 = add float %p0, %v0;

+ ret float %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 0>

+3: <2, 3, 1, 0>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="float-subtract">

+<h4 id="float-subtract">Float Subtract</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = sub T V1, V2; <a>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 1>

+</pre>

+Semantics

+The float subtract instruction returns the difference of its two

+arguments. Arguments V1 and V2, and the result %vN must be of type

+T. T must be an floating type, or a floating vector type. N is defined by

+the record position, defining the corresponding value generated by the

+instruction. A is the (optional) abbreviation ¯associated with the

+corresponding record.

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+VV1 == RelativeIndex(V1)

+VV2 == RelativeIndex(V2)

+T == TypeOf(V1) == TypeOf(V2)

+IsFloat(UnderlyingType(T))

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function float @f0(float %p0, float %p1) {

+ blocks: 1;

+%b0:

+ %v0 = sub float %p0, %p1;

+ %v1 = sub float %p0, %v0;

+ ret float %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 1>

+3: <2, 3, 1, 1>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="float-multiply">

+<h4 id="float-multiply">Float Multiply</h4>

+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.

+Syntax

+<pre class="prettyprint">

+&vN = mul T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 2>

+</pre>

+Semantics

+The multiply instruction returns the product of its two arguments. Arguments

+V1 and V2, and the result %vN must be of type T. T must be an

+floating type, or a floating vector type. N is defined by the record position,

+defining the corresponding value generated by the instruction. A is the

+(optional) abbreviation associated with the corresponding record.

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+VV1 == RelativeIndex(V1)

+VV2 == RelativeIndex(V2)

+T == TypeOf(V1) == TypeOf(V2)

+IsFloat(UnderlyingType(T))

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function float @f0(float %p0, float %p1) {

+ blocks: 1;

+%b0:

+ %v0 = mul float %p0, %p1;

+ %v1 = mul float %p0, %v0;

+ ret float %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 2>

+3: <2, 3, 1, 2>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="float-divide">

+<h4 id="float-divide">Float Divide</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = div T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, V1, V2, 4>

+</pre>

+Semantics

+The float divide instruction returns the quotient of its two

+arguments. Arguments V1 and V2, and the result %vN must be of type

+T. T must be a floating type, or a floating vector type. N is defined by

+the record position, defining the corresponding value generated by the

+instruction. A is the (optional) abbreviation associated with the

+corresponding record.

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+VV1 == RelativeIndex(V1)

+VV22 == RelativeIndex(V2)

+T == TypeOf(V1) == TypeOf(V2)

+IsFloat(UnderlyingType(T))

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function double @f0(double %p0, double %p1) {

+ blocks: 1;

+%b0:

+ %v0 = div double %p0, %p1;

+ %v1 = div double %p0, %v0;

+ ret double %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 4>

+3: <2, 3, 1, 4>

+3: <10, 1>

+0: <65534>

+</pre>

+</section><section id="float-remainder">

+<h4 id="float-remainder">Float Remainder</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = rem T V1, V2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 6>

+</pre>

+Semantics

+The float remainder instruction returns the remainder of the quotient of its two

+arguments. Arguments V1 and V2, and the result %vN must be of type

+T. T must be a floating type, or a floating vector type. N is defined by

+the record position, defining the corresponding value generated by the

+instruction. A is the (optional) abbreviation associated with the

+corresponding record.

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+VV1 == RelativeIndex(V1)

+VV2 == RelativeIndex(V2)

+T == TypeOf(V1) == TypeOf(V2)

+IsFloat(UnderlyingType(T))

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples

+<pre class="prettyprint">

+function double @f0(double %p0, double %p1) {

+ blocks: 1;

+%b0:

+ %v0 = rem double %p0, %p1;

+ %v1 = rem double %p0, %v0;

+ ret double %v1;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <2, 2, 1, 6>

+3: <2, 3, 1, 6>

+3: <10, 1>

+0: <65534>

+</pre>

+</section></section><section id="memory-creation-and-access-instructions">

+<h3 id="memory-creation-and-access-instructions">Memory creation and access Instructions</h3>

+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.

+<section id="alloca-instruction">

+<h4 id="alloca-instruction">Alloca Instruction</h4>

+The alloca instruction allocates memory on the stack frame of the

+currently executing function. This memory is automatically released

+when the function returns to its caller.

+Syntax

+<pre class="prettyprint">

+%vN = alloca i8, i32 S, align V; <A>

+%vN = alloca i8, i32 S; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <19, SS, VV>

+</pre>

+Semantics

+The alloca 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). S is the number of bytes that are allocated on the

+stack. S must be of integral type i32. V is the aligment of the generated

+stack address. A is the corresponding number of bits associated with the

+record.

+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.

+TODO(kschimpf) Other alignment issues?

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+VV == Log2(V+1)

+SS == RelativeIndex(S)

+i32 == TypeOf(S)

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = i32;

+</pre>

+Examples

+The following instructions allocates memory for a 32-bit integer and a

+64-bit floating value:

+<pre class="prettyprint">

+function void @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>

+Assuming TypeId(i32) == @t1, the corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+1: <65535, 11, 2>

+3: <1, 1>

+3: <4, 8>

+3: <4, 16>

+0: <65534>

+3: <19, 2, 0>

+3: <10>

+0: <65534>

+</pre>

+</section><section id="load-instruction">

+<h4 id="load-instruction">Load Instruction</h4>

+The load instruction is used to read from memory.

+Syntax

+<pre class="prettyprint">

+%vN = load T* P, align V; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <20, PP, VV, TT>

+</pre>

+Semantics

+The load instruction is used to read from memory. P is identifier of the

+memory address to read. The type of P must be an i32 integer. T is the type

+of value to read. V is the alignment of the memory address. A is the

+(optional) abbreviation associated with the record.

+Type T must be an integral or floating type. Both float and double types

+are allowed for floating types. All integral types except i1 is allowed.

+Valid alignment V values are:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">V</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>

+Constraints

+<blockquote>

+<div>AA == AbbrevIndex(A)

+i32 == TypeOf(P)

+PP == RelativeIndex(P)

+VV == Log2(V+1)

+%tTT == TypeID(T)

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks</div></blockquote>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T;

+</pre>

+Examples

+The following instructions load an i32 integer and a 64-bit floating value:

+<pre class="prettyprint">

+function void @f(i32 %p0) {

+ blocks: 1;

+%b0:

+ %v0 = load i32* %p0, align 1;

+ %v1 = load double* %v0, align 8;

+ ret;

+</pre>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <20, 1, 1>

+3: <20, 1, 4>

+3: <10>

+0: <65534>

+</pre>

+</section><section id="store-instruction">

+<h4 id="store-instruction">Store Instruction</h4>

+The store instruction is used to write to memory.

+Syntax

+<pre class="prettyprint">

+store T S, T* P, align V; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <24, PP, SS, VV>

+</pre>

+Semantics

+The store instruction is used to write to memory. P is the identifier of the

+memory address to write to. The type of P must be an i32 integer. T is the

+type of value to store. S is the value to store, and must be of type T. V

+is the alignment of the memory address. A is the (optional) abbreviation

+index associated with the record.

+Type T must be an integral or floating type. Both float and double types

+are allowed for floating types. All integral types except i1 is allowed.

+Valid alignment V values are:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">V</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>

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+i32 == TypeOf(P)

+PP == RelativeIndex(P)

+VV == Log2(V+1)

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Examples

+The following instructions store an i32 integer and a 32-bit floating

+value.

+<pre class="prettyprint">

+function void @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>

+The corresponding records are:

+<pre class="prettyprint">

+1: <65535, 12, 2>

+3: <1, 1>

+3: <24, 4, 3, 1>

+3: <24, 1, 2, 4>

+3: <10>

+0: <65534>

+</pre>

+</section></section><section id="conversion-instructions">

+<h3 id="conversion-instructions">Conversion Instructions</h3>

+Conversion instructions all take a single operand and a type. The

+value is converted to the corresponding type.

+<section id="integer-truncating-instruction">

+<h4 id="integer-truncating-instruction">Integer truncating Instruction</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = trunc T1 V to T2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <3, VV, TT2, 0>

+</pre>

+Semantics

+The integer truncating instruction takes a value V, and truncates to type

+T2. A is the (optional) abbreviation associated with the corresponding

+record. Both T1 and T2 must be integer types, or integral vectors of the

+same size.

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+TypeOf(V) = T1

+*VV* == RelativeIndex(*V*)

+%tTT2 = TypeID(T2)

+BitSizeOf(UnderlyingType(T1)) > BitSizeOf(UnderlyingType(T2))

+UnderlyingCount(T1) == UnderlyingCount(T2)

+IsInteger(UnderlyingType(T1))

+IsInteger(UnderlyingType(T2))

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T2;

+</pre>

+Examples

+<pre class="prettyprint">

+%v10 = trunc i32 %v9 to i8;

+</pre>

+Assuming

+<pre class="prettyprint">

+@t2 = i8;

+</pre>

+the corresponding record is:

+<pre class="prettyprint">

+<3, 1, 2, 0>

+</pre>

+</section><section id="floating-truncating-instruction">

+<h4 id="floating-truncating-instruction">Floating truncating Instruction</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = fptrunc T1 V to T2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <3, VV, TT2, 7>

+</pre>

+Semantics

+The floating truncating instruction takes a value V, and truncates to type

+T2. A is the (optional) abbreviation associated with the corresponding

+record. Both T1 and T2 must be integer types, or integral vectors of the

+same size.

+If the value can’t fit within the destination type T2, the results are

+undefined.

+Constraints

+<pre class="prettyprint">

+TypeOf(V) = T1

+double == UnderlyingType(T1)

+float == UnderlyingType(T2)

+*VV* == RelativeIndex(*V*)

+%tTT2 = TypeID(T2)

+BitSizeOf(UnderlyingType(T1)) > BitSizeOf(UnderlyingType(T2))

+UnderlyingCount(T1) == UnderlyingCount(T2)

+IsFloat(UnderlyingType(T1))

+IsFloat(UnderlyingType(T2))

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T2;

+</pre>

+Examples

+<pre class="prettyprint">

+%v10 = fptrunc double %v9 to float;

+</pre>

+Assuming

+<pre class="prettyprint">

+@t4 = float;

+</pre>

+the corresponding record is:

+<pre class="prettyprint">

+<3, 1, 4, 7>

+</pre>

+</section><section id="zero-extending-instruction">

+<h4 id="zero-extending-instruction">Zero Extending Instruction</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = zext T1 V to T2; <A>

+</pre>

+Record

+<pre class="prettyprint">

+AA: <3, VV, TT2, 1>

+</pre>

+Semantics

+The zero extending instruction takes a value V, and expands it to type

+T2. I is the (optional) abbreviation associated with the corresponding

+record. Both T1 and T2 must be integer types, or vectors of the same number

+of integers.

+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.

+Constraints

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+TypeOf(V) = T1

+*VV* == RelativeIndex(*V*)

+%tTT2 = TypeID(T2)

+BitSizeOf(UnderlyingType(T1)) < BitSizeOf(UnderlyingType(T2))

+UnderlyingCount(T1) == UnderlyingCount(T2)

+IsInteger(UnderlyingType(T1))

+IsInteger(UnderlyingType(T2))

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T2;

+</pre>

+Examples

+<pre class="prettyprint">

+%v12 = zext i8 %v11 to i32;

+</pre>

+Assuming

+<pre class="prettyprint">

+@t0 = i32;

+</pre>

+the corresponding record is:

+<pre class="prettyprint">

+<3, 1, 0, 2>

+</pre>

+</section><section id="sign-extending-instruction">

+<h4 id="sign-extending-instruction">Sign Extending Instruction</h4>

+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.

+Syntax

+<pre class="prettyprint">

+%vN = sext T1 V to T2;

+</pre>

+Record

+<pre class="prettyprint">

+I: <3, VV, TT2, 2>

+</pre>

+Semantics

+The sign extending instruction takes a value V, and expands it to

+type T2. VV is the relative index of V. I is the (optional)

+abbreviation associated with the corresponding record. Both T1 and

+T2 must be integer types, or vectors of the same number of integers.

+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.

+Constraints

+<pre class="prettyprint">

+TypeOf(V) = T1

+*VV* == RelativeIndex(*V*)

+%tTT2 = TypeID(T2)

+BitSizeOf(UnderlyingType(T1)) < BitSizeOf(UnderlyingType(T2))

+UnderlyingCount(T1) == UnderlyingCount(T2)

+IsInteger(UnderlyingType(T1))

+IsInteger(UnderlyingType(T2))

+N == NumValuedInsts

+NumBasicBlocks < ExpectedBasicBlocks

+</pre>

+Updates

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T2;

+</pre>

+Examples

+<pre class="prettyprint">

+%v12 = sext i8 %v11 to i32;

+</pre>

+Assuming

+<pre class="prettyprint">

+@t0 = i32;

+</pre>

+the corresponding record is:

+<pre class="prettyprint">

+<3, 1, 0, 2>

+</pre>

+</section><section id="fpext">

+<h4 id="fpext">fpext</h4>

+TODO(kschimpf)

+</section><section id="fptoui">

+<h4 id="fptoui">fptoui</h4>

+TODO(kschimpf)

+</section><section id="fptosi">

+<h4 id="fptosi">fptosi</h4>

+TODO(kschimpf)

+</section><section id="sitofp">

+<h4 id="sitofp">sitofp</h4>

+TODO(kschimpf)

+</section><section id="bitcast">

+<h4 id="bitcast">bitcast</h4>

+TODO(kschimpf)

+</section></section><section id="comparison-instructions">

+<h3 id="comparison-instructions">Comparison Instructions</h3>

+TODO(kschimpf): cmp

+</section><section id="other-instructions">

+<h3 id="other-instructions">Other Instructions</h3>

+TODO(kschimpf)

+<section id="phi-instruction">

+<h4 id="phi-instruction">Phi Instruction</h4>

+TODO(kschimpf)

+</section><section id="forward-type-declarations">

+<h4 id="forward-type-declarations">Forward type declarations</h4>

+TODO(kschimpf)

+</section><section id="select-instruction">

+<h4 id="select-instruction">Select Instruction</h4>

+TODO(kschimpf)

+</section><section id="call-instructions">

+<h4 id="call-instructions">Call Instructions</h4>

+TODO(kschimpf)

+</section></section><section id="intrinsic-functions">

+<h3 id="intrinsic-functions">Intrinsic Functions</h3>

+TODO(kschimpf)

+</section></section><section id="support-functions">

+<h2 id="support-functions">Support Functions</h2>

+Defines functions used to convert syntactic representation to corresponding

+records.

+<section id="signrotate">

+<h3 id="signrotate">SignRotate</h3>

+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.

+The definition of SignRotate(N) is:

+<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)<<1</td>

+<td>N >= 0</td>

+</tr>

+<tr class="row-odd"><td>N</td>

+<td>abs(N)<<1 + 1</td>

+<td>N < 0</td>

+</tr>

+</tbody>

+</table>

+</section><section id="absoluteindex">

+<h3 id="absoluteindex">AbsoluteIndex</h3>

+Bitcode ID’s of the forms @fN, @gN, %pN, %cN, and %vN, 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.

+Hence, within a function block, it is safe to refer to all of these

+bitcode IDs using a single absolute index. The abolute index for

+each kind of bitcode ID is computed as follows:

+<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>@fN</td>

+<td>N</td>

+</tr>

+<tr class="row-odd"><td>@gN</td>

+<td>N + NumDefinedFcnAddresses</td>

+</tr>

+<tr class="row-even"><td>@pN</td>

+<td>N + NumDefinedFcnAddresses + NumGlobalAddresses</td>

+</tr>

+<tr class="row-odd"><td>@cN</td>

+<td>N + NumDefinedFcnAddresses + NumGlobalAddresses + NumParams</td>

+</tr>

+<tr class="row-even"><td>@vN</td>

+<td>N + NumDefinedFcnAddresses + NumGlobalAddresses + NumParams + NumFcnConsts</td>

+</tr>

+</tbody>

+</table>

+</section><section id="relativeindex">

+<h3 id="relativeindex">RelativeIndex</h3>

+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:

+<pre class="prettyprint">

+RelativeIndex(J) = AbsoluteIndex(NumValuedInsts) - AbsoluteIndex(J)

+</pre>

+</section><section id="abbrevindex">

+<h3 id="abbrevindex">AbbrevIndex</h3>

+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).

+<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>@aA</td>

+<td>A + 4</td>

+</tr>

+</tbody>

+</table>

+</section><section id="log2">

+<h3 id="log2">Log2</h3>

+This is the 32-bit log2 value of its argument.

+</section><section id="exp">

+<h3 id="exp">exp</h3>

+<pre class="prettyprint">

+exp(n, m)

+</pre>

+Denotes the m power of n.

+</section><section id="bitsizeof">

+<h3 id="bitsizeof">BitSizeOf</h3>

+Returns the number of bits needed to represent its argument (a type).

+</section><section id="underlyingtype">

+<h3 id="underlyingtype">UnderlyingType</h3>

+Returns the primitive type of the type construct. For primitive types,

+the UnderlyingType is itself. For vector types, the base type of the

+vector is the underlying type.

+</section><section id="underlyingcount">

+<h3 id="underlyingcount">UnderlyingCount</h3>

+Returns the number of primitive types in the construct. For primitive

+types, the UnderlyingCount is 1. For vector types, it returns the

+number of elements in the vector.

+</section><section id="isinteger">

+<h3 id="isinteger">IsInteger</h3>

+Returns true if the argument is in {i1, i8, i16, i32, i64}.

+</section><section id="isfloat">

+<h3 id="isfloat">IsFloat</h3>

+Returns true if the argument is in {float, double}.

+</section><section id="abbreviations">

+<h3 id="abbreviations">Abbreviations</h3>

+TODO(kschimpf)

+<section id="id4">

+<h4 id="id4">Introduction</h4>

+TODO(kschimpf)

+<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>

+TODO(kschimpf)

+<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>

+TODO(kschimpf)

+</section></section></section>

+{{/partials.standard_nacl_article}}