diff options
| -rw-r--r-- | docs/BytecodeFormat.html | 248 | ||||
| -rw-r--r-- | docs/index.html | 1 |
2 files changed, 249 insertions, 0 deletions
diff --git a/docs/BytecodeFormat.html b/docs/BytecodeFormat.html new file mode 100644 index 0000000..3169f16 --- /dev/null +++ b/docs/BytecodeFormat.html @@ -0,0 +1,248 @@ +<!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 +--> diff --git a/docs/index.html b/docs/index.html index 32664b2..2429b86 100644 --- a/docs/index.html +++ b/docs/index.html @@ -114,6 +114,7 @@ useful for those writing front-ends.</li> <li><a href="CommandLine.html">Command Line Library</a></li> <li><a href="ExtendingLLVM.html">Extending LLVM</a></li> <li><a href="CodingStandards.html">Coding Standards</a></li> +<li><a href="BytecodeFormat.html">LLVM Bytecode File Format</a></li> </ul> </div> |