| <?xml version="1.0" encoding="utf-8" ?> |
| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |
| <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" /> |
| <title>libbcc: A Versatile Bitcode Execution Engine for Mobile Devices</title> |
| <style type="text/css"> |
| |
| /* |
| :Author: David Goodger (goodger@python.org) |
| :Id: $Id: html4css1.css 5951 2009-05-18 18:03:10Z milde $ |
| :Copyright: This stylesheet has been placed in the public domain. |
| |
| Default cascading style sheet for the HTML output of Docutils. |
| |
| See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to |
| customize this style sheet. |
| */ |
| |
| /* used to remove borders from tables and images */ |
| .borderless, table.borderless td, table.borderless th { |
| border: 0 } |
| |
| table.borderless td, table.borderless th { |
| /* Override padding for "table.docutils td" with "! important". |
| The right padding separates the table cells. */ |
| padding: 0 0.5em 0 0 ! important } |
| |
| .first { |
| /* Override more specific margin styles with "! important". */ |
| margin-top: 0 ! important } |
| |
| .last, .with-subtitle { |
| margin-bottom: 0 ! important } |
| |
| .hidden { |
| display: none } |
| |
| a.toc-backref { |
| text-decoration: none ; |
| color: black } |
| |
| blockquote.epigraph { |
| margin: 2em 5em ; } |
| |
| dl.docutils dd { |
| margin-bottom: 0.5em } |
| |
| /* Uncomment (and remove this text!) to get bold-faced definition list terms |
| dl.docutils dt { |
| font-weight: bold } |
| */ |
| |
| div.abstract { |
| margin: 2em 5em } |
| |
| div.abstract p.topic-title { |
| font-weight: bold ; |
| text-align: center } |
| |
| div.admonition, div.attention, div.caution, div.danger, div.error, |
| div.hint, div.important, div.note, div.tip, div.warning { |
| margin: 2em ; |
| border: medium outset ; |
| padding: 1em } |
| |
| div.admonition p.admonition-title, div.hint p.admonition-title, |
| div.important p.admonition-title, div.note p.admonition-title, |
| div.tip p.admonition-title { |
| font-weight: bold ; |
| font-family: sans-serif } |
| |
| div.attention p.admonition-title, div.caution p.admonition-title, |
| div.danger p.admonition-title, div.error p.admonition-title, |
| div.warning p.admonition-title { |
| color: red ; |
| font-weight: bold ; |
| font-family: sans-serif } |
| |
| /* Uncomment (and remove this text!) to get reduced vertical space in |
| compound paragraphs. |
| div.compound .compound-first, div.compound .compound-middle { |
| margin-bottom: 0.5em } |
| |
| div.compound .compound-last, div.compound .compound-middle { |
| margin-top: 0.5em } |
| */ |
| |
| div.dedication { |
| margin: 2em 5em ; |
| text-align: center ; |
| font-style: italic } |
| |
| div.dedication p.topic-title { |
| font-weight: bold ; |
| font-style: normal } |
| |
| div.figure { |
| margin-left: 2em ; |
| margin-right: 2em } |
| |
| div.footer, div.header { |
| clear: both; |
| font-size: smaller } |
| |
| div.line-block { |
| display: block ; |
| margin-top: 1em ; |
| margin-bottom: 1em } |
| |
| div.line-block div.line-block { |
| margin-top: 0 ; |
| margin-bottom: 0 ; |
| margin-left: 1.5em } |
| |
| div.sidebar { |
| margin: 0 0 0.5em 1em ; |
| border: medium outset ; |
| padding: 1em ; |
| background-color: #ffffee ; |
| width: 40% ; |
| float: right ; |
| clear: right } |
| |
| div.sidebar p.rubric { |
| font-family: sans-serif ; |
| font-size: medium } |
| |
| div.system-messages { |
| margin: 5em } |
| |
| div.system-messages h1 { |
| color: red } |
| |
| div.system-message { |
| border: medium outset ; |
| padding: 1em } |
| |
| div.system-message p.system-message-title { |
| color: red ; |
| font-weight: bold } |
| |
| div.topic { |
| margin: 2em } |
| |
| h1.section-subtitle, h2.section-subtitle, h3.section-subtitle, |
| h4.section-subtitle, h5.section-subtitle, h6.section-subtitle { |
| margin-top: 0.4em } |
| |
| h1.title { |
| text-align: center } |
| |
| h2.subtitle { |
| text-align: center } |
| |
| hr.docutils { |
| width: 75% } |
| |
| img.align-left, .figure.align-left{ |
| clear: left ; |
| float: left ; |
| margin-right: 1em } |
| |
| img.align-right, .figure.align-right { |
| clear: right ; |
| float: right ; |
| margin-left: 1em } |
| |
| .align-left { |
| text-align: left } |
| |
| .align-center { |
| clear: both ; |
| text-align: center } |
| |
| .align-right { |
| text-align: right } |
| |
| /* reset inner alignment in figures */ |
| div.align-right { |
| text-align: left } |
| |
| /* div.align-center * { */ |
| /* text-align: left } */ |
| |
| ol.simple, ul.simple { |
| margin-bottom: 1em } |
| |
| ol.arabic { |
| list-style: decimal } |
| |
| ol.loweralpha { |
| list-style: lower-alpha } |
| |
| ol.upperalpha { |
| list-style: upper-alpha } |
| |
| ol.lowerroman { |
| list-style: lower-roman } |
| |
| ol.upperroman { |
| list-style: upper-roman } |
| |
| p.attribution { |
| text-align: right ; |
| margin-left: 50% } |
| |
| p.caption { |
| font-style: italic } |
| |
| p.credits { |
| font-style: italic ; |
| font-size: smaller } |
| |
| p.label { |
| white-space: nowrap } |
| |
| p.rubric { |
| font-weight: bold ; |
| font-size: larger ; |
| color: maroon ; |
| text-align: center } |
| |
| p.sidebar-title { |
| font-family: sans-serif ; |
| font-weight: bold ; |
| font-size: larger } |
| |
| p.sidebar-subtitle { |
| font-family: sans-serif ; |
| font-weight: bold } |
| |
| p.topic-title { |
| font-weight: bold } |
| |
| pre.address { |
| margin-bottom: 0 ; |
| margin-top: 0 ; |
| font: inherit } |
| |
| pre.literal-block, pre.doctest-block { |
| margin-left: 2em ; |
| margin-right: 2em } |
| |
| span.classifier { |
| font-family: sans-serif ; |
| font-style: oblique } |
| |
| span.classifier-delimiter { |
| font-family: sans-serif ; |
| font-weight: bold } |
| |
| span.interpreted { |
| font-family: sans-serif } |
| |
| span.option { |
| white-space: nowrap } |
| |
| span.pre { |
| white-space: pre } |
| |
| span.problematic { |
| color: red } |
| |
| span.section-subtitle { |
| /* font-size relative to parent (h1..h6 element) */ |
| font-size: 80% } |
| |
| table.citation { |
| border-left: solid 1px gray; |
| margin-left: 1px } |
| |
| table.docinfo { |
| margin: 2em 4em } |
| |
| table.docutils { |
| margin-top: 0.5em ; |
| margin-bottom: 0.5em } |
| |
| table.footnote { |
| border-left: solid 1px black; |
| margin-left: 1px } |
| |
| table.docutils td, table.docutils th, |
| table.docinfo td, table.docinfo th { |
| padding-left: 0.5em ; |
| padding-right: 0.5em ; |
| vertical-align: top } |
| |
| table.docutils th.field-name, table.docinfo th.docinfo-name { |
| font-weight: bold ; |
| text-align: left ; |
| white-space: nowrap ; |
| padding-left: 0 } |
| |
| h1 tt.docutils, h2 tt.docutils, h3 tt.docutils, |
| h4 tt.docutils, h5 tt.docutils, h6 tt.docutils { |
| font-size: 100% } |
| |
| ul.auto-toc { |
| list-style-type: none } |
| |
| </style> |
| </head> |
| <body> |
| <div class="document" id="libbcc-a-versatile-bitcode-execution-engine-for-mobile-devices"> |
| <h1 class="title">libbcc: A Versatile Bitcode Execution Engine for Mobile Devices</h1> |
| |
| <div class="section" id="introduction"> |
| <h1>Introduction</h1> |
| <p>libbcc is an LLVM bitcode execution engine that compiles the bitcode |
| to an in-memory executable. libbcc is versatile because:</p> |
| <ul class="simple"> |
| <li>it implements both AOT (Ahead-of-Time) and JIT (Just-in-Time) |
| compilation.</li> |
| <li>Android devices demand fast start-up time, small size, and high |
| performance <em>at the same time</em>. libbcc attempts to address these |
| design constraints.</li> |
| <li>it supports on-device linking. Each device vendor can supply their |
| own runtime bitcode library (lib*.bc) that differentiates their |
| system. Specialization becomes ecosystem-friendly.</li> |
| </ul> |
| <p>libbcc provides:</p> |
| <ul class="simple"> |
| <li>a <em>just-in-time bitcode compiler</em>, which translates the LLVM bitcode |
| into machine code</li> |
| <li>a <em>caching mechanism</em>, which can:<ul> |
| <li>after each compilation, serialize the in-memory executable into a |
| cache file. Note that the compilation is triggered by a cache |
| miss.</li> |
| <li>load from the cache file upon cache-hit.</li> |
| </ul> |
| </li> |
| </ul> |
| <p>Highlights of libbcc are:</p> |
| <ul> |
| <li><p class="first">libbcc supports bitcode from various language frontends, such as |
| Renderscript, GLSL (pixelflinger2).</p> |
| </li> |
| <li><p class="first">libbcc strives to balance between library size, launch time and |
| steady-state performance:</p> |
| <ul> |
| <li><p class="first">The size of libbcc is aggressively reduced for mobile devices. We |
| customize and improve upon the default Execution Engine from |
| upstream. Otherwise, libbcc's execution engine can easily become |
| at least 2 times bigger.</p> |
| </li> |
| <li><p class="first">To reduce launch time, we support caching of |
| binaries. Just-in-Time compilation are oftentimes Just-too-Late, |
| if the given apps are performance-sensitive. Thus, we implemented |
| AOT to get the best of both worlds: Fast launch time and high |
| steady-state performance.</p> |
| <p>AOT is also important for projects such as NDK on LLVM with |
| portability enhancement. Launch time reduction after we |
| implemented AOT is signficant:</p> |
| <pre class="literal-block"> |
| Apps libbcc without AOT libbcc with AOT |
| launch time in libbcc launch time in libbcc |
| App_1 1218ms 9ms |
| App_2 842ms 4ms |
| Wallpaper: |
| MagicSmoke 182ms 3ms |
| Halo 127ms 3ms |
| Balls 149ms 3ms |
| SceneGraph 146ms 90ms |
| Model 104ms 4ms |
| Fountain 57ms 3ms |
| </pre> |
| <p>AOT also masks the launching time overhead of on-device linking |
| and helps it become reality.</p> |
| </li> |
| <li><p class="first">For steady-state performance, we enable VFP3 and aggressive |
| optimizations.</p> |
| </li> |
| </ul> |
| </li> |
| <li><p class="first">Currently we disable Lazy JITting.</p> |
| </li> |
| </ul> |
| </div> |
| <div class="section" id="api"> |
| <h1>API</h1> |
| <p><strong>Basic:</strong></p> |
| <ul class="simple"> |
| <li><strong>bccCreateScript</strong> - Create new bcc script</li> |
| <li><strong>bccRegisterSymbolCallback</strong> - Register the callback function for external |
| symbol lookup</li> |
| <li><strong>bccReadBC</strong> - Set the source bitcode for compilation</li> |
| <li><strong>bccReadModule</strong> - Set the llvm::Module for compilation</li> |
| <li><strong>bccLinkBC</strong> - Set the library bitcode for linking</li> |
| <li><strong>bccPrepareExecutable</strong> - <em>deprecated</em> - Use bccPrepareExecutableEx instead</li> |
| <li><strong>bccPrepareExecutableEx</strong> - Create the in-memory executable by either |
| just-in-time compilation or cache loading</li> |
| <li><strong>bccGetFuncAddr</strong> - Get the entry address of the function</li> |
| <li><strong>bccDisposeScript</strong> - Destroy bcc script and release the resources</li> |
| <li><strong>bccGetError</strong> - <em>deprecated</em> - Don't use this</li> |
| </ul> |
| <p><strong>Reflection:</strong></p> |
| <ul class="simple"> |
| <li><strong>bccGetExportVarCount</strong> - Get the count of exported variables</li> |
| <li><strong>bccGetExportVarList</strong> - Get the addresses of exported variables</li> |
| <li><strong>bccGetExportFuncCount</strong> - Get the count of exported functions</li> |
| <li><strong>bccGetExportFuncList</strong> - Get the addresses of exported functions</li> |
| <li><strong>bccGetPragmaCount</strong> - Get the count of pragmas</li> |
| <li><strong>bccGetPragmaList</strong> - Get the pragmas</li> |
| </ul> |
| <p><strong>Debug:</strong></p> |
| <ul class="simple"> |
| <li><strong>bccGetFuncCount</strong> - Get the count of functions (including non-exported)</li> |
| <li><strong>bccGetFuncInfoList</strong> - Get the function information (name, base, size)</li> |
| </ul> |
| </div> |
| <div class="section" id="cache-file-format"> |
| <h1>Cache File Format</h1> |
| <p>A cache file (denoted as *.oBCC) for libbcc consists of several sections: |
| header, string pool, dependencies table, relocation table, exported |
| variable list, exported function list, pragma list, function information |
| table, and bcc context. Every section should be aligned to a word size. |
| Here is the brief description of each sections:</p> |
| <ul class="simple"> |
| <li><strong>Header</strong> (MCO_Header) - The header of a cache file. It contains the |
| magic word, version, machine integer type information (the endianness, |
| the size of off_t, size_t, and ptr_t), and the size |
| and offset of other sections. The header section is guaranteed |
| to be at the beginning of the cache file.</li> |
| <li><strong>String Pool</strong> (MCO_StringPool) - A collection of serialized variable |
| length strings. The strp_index in the other part of the cache file |
| represents the index of such string in this string pool.</li> |
| <li><strong>Dependencies Table</strong> (MCO_DependencyTable) - The dependencies table. |
| This table stores the resource name (or file path), the resource |
| type (rather in APK or on the file system), and the SHA1 checksum.</li> |
| <li><strong>Relocation Table</strong> (MCO_RelocationTable) - <em>not enabled</em></li> |
| <li><strong>Exported Variable List</strong> (MCO_ExportVarList) - |
| The list of the addresses of exported variables.</li> |
| <li><strong>Exported Function List</strong> (MCO_ExportFuncList) - |
| The list of the addresses of exported functions.</li> |
| <li><strong>Pragma List</strong> (MCO_PragmaList) - The list of pragma key-value pair.</li> |
| <li><strong>Function Information Table</strong> (MCO_FuncTable) - This is a table of |
| function information, such as function name, function entry address, |
| and function binary size. Besides, the table should be ordered by |
| function name.</li> |
| <li><strong>Context</strong> - The context of the in-memory executable, including |
| the code and the data. The offset of context should aligned to |
| a page size, so that we can mmap the context directly into memory.</li> |
| </ul> |
| <p>For furthur information, you may read <a class="reference external" href="include/bcc/bcc_cache.h">bcc_cache.h</a>, |
| <a class="reference external" href="lib/bcc/CacheReader.cpp">CacheReader.cpp</a>, and |
| <a class="reference external" href="lib/bcc/CacheWriter.cpp">CacheWriter.cpp</a> for details.</p> |
| </div> |
| <div class="section" id="jit-ed-code-calling-conventions"> |
| <h1>JIT'ed Code Calling Conventions</h1> |
| <ol class="arabic"> |
| <li><p class="first">Calls from Execution Environment or from/to within script:</p> |
| <p>On ARM, the first 4 arguments will go into r0, r1, r2, and r3, in that order. |
| The remaining (if any) will go through stack.</p> |
| <p>For ext_vec_types such as float2, a set of registers will be used. In the case |
| of float2, a register pair will be used. Specifically, if float2 is the first |
| argument in the function prototype, float2.x will go into r0, and float2.y, |
| r1.</p> |
| <p>Note: stack will be aligned to the coarsest-grained argument. In the case of |
| float2 above as an argument, parameter stack will be aligned to an 8-byte |
| boundary (if the sizes of other arguments are no greater than 8.)</p> |
| </li> |
| <li><p class="first">Calls from/to a separate compilation unit: (E.g., calls to Execution |
| Environment if those runtime library callees are not compiled using LLVM.)</p> |
| <p>On ARM, we use hardfp. Note that double will be placed in a register pair.</p> |
| </li> |
| </ol> |
| </div> |
| </div> |
| </body> |
| </html> |