mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-08-19 04:29:21 +00:00
249 lines
11 KiB
HTML
249 lines
11 KiB
HTML
|
<!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
|
||
|
|
-->
|