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