--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+ <title>LLVM Bytecode File Format</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ <style>
+ table, tr, td { border: 2px solid gray }
+ th { border: 2px sold gray; font-weight: bold; }
+ table { border-collapse: collapse; margin-top: 1em margin-bottom: 1em }
+ </style>
+</head>
+<body>
+ <div class="doc_title"> LLVM Bytecode File Format </div>
+<ol>
+ <li><a href="#abstract">Abstract</a></li>
+ <li><a href="#general">General Concepts</a></li>
+ <ol>
+ <li><a href="#blocks">Blocks</a></li>
+ <li><a href="#lists">Lists</a></li>
+ <li><a href="#fields">Fields</a></li>
+ <li><a href="#align">Alignment</a></li>
+ </ol>
+ <li><a href="#details">Detailed Layout</a>
+ <ol>
+ <li><a href="#notation">Notation</a></li>
+ <li><a href="#blocktypes">Blocks Types</a></li>
+ <li><a href="#header">Header Block</a></li>
+ <li><a href="#typeool">Global Type Pool</a></li>
+ <li><a href="#modinfo">Module Info Block</a></li>
+ <li><a href="#constants">Global Constant Pool</a></li>
+ <li><a href="#functions">Function Blocks</a><li>
+ <li><a href="#symtab">Module Symbol Table</a><li>
+ </ol>
+ </li>
+</ol>
+<div class="doc_text">
+<p><b>Written by <a href="mailto:rspencer@x10sys.com">Reid Spencer</a>
+and <a href="mailto:sabre@nondot.org">Chris Lattner</a></b></p>
+<p> </p>
+</div>
+<!-- *********************************************************************** -->
+<div class="doc_section"> <a name="abstract">Abstract </a></div>
+<!-- *********************************************************************** -->
+<div class="doc_text">
+<p>This document is an (after the fact) specification of the LLVM bytecode
+file format. It documents the binary encoding rules of the bytecode file format
+so that equivalent systems can encode bytecode files correctly. The LLVM
+bytecode representation is used to store the intermediate representation on
+disk in compacted form.
+</p>
+</div>
+<!-- *********************************************************************** -->
+<div class="doc_section"> <a name="general">General Concepts</a> </div>
+<!-- *********************************************************************** -->
+<div class="doc_text">
+<p>This section describes the general concepts of the bytecode file format
+without getting into bit and byte level specifics.</p>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="blocks">Blocks</a> </div>
+<div class="doc_text">
+<p>LLVM bytecode files consist simply of a sequence of blocks of bytes.
+Each block begins with an identification value that determines the type of
+the next block. The possible types of blocks are described below in the section
+<a href="#blockstypes">Block Types</a>. The block identifier is used because
+it is possible for entire blocks to be omitted from the file if they are
+empty. The block identifier helps the reader determine which kind of block is
+next in the file.</p>
+<p>
+Except for the <a href="#header">Header Block</a> all blocks are variable
+length. The consume just enough bytes to express their contents.</p>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="lists">Lists</a> </div>
+<div class="doc_text">
+<p>Most blocks are constructed of lists of information. Lists can be constructed
+of other lists, etc. This decomposition of information follows the containment
+hierarchy of the LLVM Intermediate Representation. For example, a function is
+composed of a list of basic blocks. Each basic block is composed of a set of
+instructions. This list of list nesting and hierarchy is maintained in the
+bytecode file.</p>
+<p>A list is encoded into the file simply by encoding the number of entries as
+an integer followed by each of the entries. The reader knows when the list is
+done because it will have filled the list with the required numbe of entries.
+</p>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="fields">Fields</a> </div>
+<div class="doc_text">
+<p>Fields are units of information that LLVM knows how to write atomically.
+Most fields have a uniform length or some kind of length indication built into
+their encoding. For example, a constant string (array of SByte or UByte) is
+written simply as the length followed by the characters. Although this is
+similar to a list, constant strings are treated atomically and are thus
+fields.</p>
+<p>Fields use a condensed bit format specific to the type of information
+they must contain. As few bits as possible are written for each field. The
+sections that follow will provide the details on how these fields are
+written and how the bits are to be interpreted.</p>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="align">Alignment</a> </div>
+<div class="doc_text">
+<p>To support cross-platform differences, the bytecode file is aligned on
+certain boundaries. This means that a small amount of padding (at most 3 bytes)
+will be added to ensure that the next entry is aligned to a 32-bit boundary.
+</p>
+</div>
+<!-- *********************************************************************** -->
+<div class="doc_section"> <a name="details">Detailed Layout</a> </div>
+<!-- *********************************************************************** -->
+<div class="doc_text">
+ <p>This section provides the detailed layout of the LLVM bytecode file format.
+ bit and byte level specifics.</p>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="notation">Notation</a></div>
+<div class="doc_text">
+ <p>The descriptions of the bytecode format that follow describe the bit
+ fields in detail. These descriptions are provided in tabular form. Each table
+ has four columns that specify:</p>
+ <ol>
+ <li><b>Byte(s)</b>. The offset in bytes of the field from the start of
+ its container (block, list, other field).<li>
+ <li><b>Bit(s)</b>. The offset in bits of the field from the start of
+ the byte field. Bits are always little endian. That is, bit addresses with
+ smaller values have smaller address (i.e. 2^0 is at bit 0, 2^1 at 1, etc.)
+ </li>
+ <li><b>Align?</b> Indicates if this field is aligned to 32 bits or not.
+ This indicates where the <em>next</em> field starts, always on a 32 bit
+ boundary.</li>
+ <li><b>Description</b>. Descripts the contents of the field.</li>
+ </ol>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="blocktypes">Block Types</a></div>
+<div class="doc_text">
+ <p>The bytecode format encodes the intermediate representation into groups
+ of bytes known as blocks. The blocks are written sequentially to the file in
+ the following order:</p>
+<ol>
+ <li><a href="#header">Header</a>. This block contains the file signature
+ (magic number), machine description and file format version (not LLVM
+ version).</li>
+ <li><a href="#gtypepool">Global Type Pool</a>. This block contains all the
+ global (module) level types.</li>
+ <li><a href="#modinfo">Module Info</a>. This block contains the types of the
+ global variables and functions in the module as well as the constant
+ initializers for the global variables</li>
+ <li><a href="#constants">Constants</a>. This block contains all the global
+ constants except function arguments, global values and constant strings.</li>
+ <li><a href="#functions">Functions</a>. One function block is written for
+ each function in the module. </li>
+ <li><a href="$symtab">Symbol Table</a>. The module level symbol table that
+ provides names for the various other entries in the file is the final block
+ written.</li>
+</ol>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="header">Header Block</a> </div>
+<div class="doc_text">
+<p>The Header Block occurs in every LLVM bytecode file and is always first. It
+simply provides a few bytes of data to identify the file, its format, and the
+bytecode version. This block is fixed length and always eight bytes, as follows:
+<table class="doc_table" width="90%">
+ <tr>
+ <th><b>Byte(s)</b></th>
+ <th><b>Bit(s)</b></th>
+ <th><b>Align?</b></th>
+ <th align="left"><b>Field Description</b></th>
+ </tr>
+ <tr>
+ <td>00</td><td>00-07</td><td>No</td>
+ <td align="left">Constant "l"</td>
+ </tr>
+ <tr>
+ <td>01</td><td>00-07</td><td>No</td>
+ <td align="left">Constant "l"</td>
+ </tr>
+ <tr>
+ <td>02</td><td>00-07</td><td>No</td>
+ <td align="left">Constant "v"</td>
+ </tr>
+ <tr>
+ <td>03</td><td>00-07</td><td>No</td>
+ <td align="left">Constant "m"</td>
+ </tr>
+ <tr>
+ <td>04-07</td><td>00</td><td>No</td>
+ <td align="left">Target is big endian</td>
+ </tr>
+ <tr>
+ <td>04-07</td><td>01</td><td>No</td>
+ <td align="left">Target has long pointers</td>
+ </tr>
+ <tr>
+ <td>04-07</td><td>02</td><td>No</td>
+ <td align="left">Target has no endianess</td>
+ </tr>
+ <tr>
+ <td>04-07</td><td>03</td><td>No</td>
+ <td align="left">Target has no pointer size</td>
+ </tr>
+ <tr>
+ <td>04-07</td><td>04-31</td><td>Yes</td>
+ <td align="left">The LLVM bytecode format version number</td>
+ </tr>
+</table>
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="gtypepool">Global Type Pool</a> </div>
+<div class="doc_text">
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="modinfo">Module Info</a> </div>
+<div class="doc_text">
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="constants">Constants</a> </div>
+<div class="doc_text">
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="functions">Functions</a> </div>
+<div class="doc_text">
+</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="symtab">Module Symbol Table</a> </div>
+<div class="doc_text">
+</div>
+
+<!-- *********************************************************************** -->
+<hr>
+<address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
+
+ <a href="mailto:rspencer@x10sys.com">Reid Spencer</a> and
+ <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date$
+</address>
+</body>
+</html>
+<!-- vim: sw=2
+-->
projects / oota-llvm.git / commitdiff