| OLD | NEW |
|---|
| (Empty) | |
| 1 {{+bindTo:partials.standard_nacl_article}} |
| 2 |
| 3 <section id="pnacl-c-c-language-support"> |
| 4 <h1 id="pnacl-c-c-language-support">PNaCl C/C++ Language Support</h1> |
| 5 <div class="contents local topic" id="contents"> |
| 6 <ul class="small-gap"> |
| 7 <li><p class="first"><a class="reference internal" href="#source-language-suppor
t" id="id2">Source language support</a></p> |
| 8 <ul class="small-gap"> |
| 9 <li><a class="reference internal" href="#preprocessor-definitions" id="id3">Prep
rocessor definitions</a></li> |
| 10 </ul> |
| 11 </li> |
| 12 <li><p class="first"><a class="reference internal" href="#memory-model-and-atomi
cs" id="id4">Memory Model and Atomics</a></p> |
| 13 <ul class="small-gap"> |
| 14 <li><a class="reference internal" href="#memory-model-for-concurrent-operations"
id="id5">Memory Model for Concurrent Operations</a></li> |
| 15 <li><a class="reference internal" href="#atomic-memory-ordering-constraints" id=
"id6">Atomic Memory Ordering Constraints</a></li> |
| 16 <li><a class="reference internal" href="#volatile-memory-accesses" id="id7">Vola
tile Memory Accesses</a></li> |
| 17 </ul> |
| 18 </li> |
| 19 <li><a class="reference internal" href="#threading" id="id8">Threading</a></li> |
| 20 <li><a class="reference internal" href="#setjmp-and-longjmp" id="id9"><code>setj
mp</code> and <code>longjmp</code></a></li> |
| 21 <li><a class="reference internal" href="#c-exception-handling" id="id10">C++ Exc
eption Handling</a></li> |
| 22 <li><a class="reference internal" href="#inline-assembly" id="id11">Inline Assem
bly</a></li> |
| 23 <li><p class="first"><a class="reference internal" href="#future-directions" id=
"id12">Future Directions</a></p> |
| 24 <ul class="small-gap"> |
| 25 <li><a class="reference internal" href="#simd" id="id13">SIMD</a></li> |
| 26 <li><a class="reference internal" href="#inter-process-communication" id="id14">
Inter-Process Communication</a></li> |
| 27 <li><a class="reference internal" href="#posix-style-signal-handling" id="id15">
POSIX-style Signal Handling</a></li> |
| 28 <li><a class="reference internal" href="#computed-goto" id="id16">Computed <code
>goto</code></a></li> |
| 29 </ul> |
| 30 </li> |
| 31 </ul> |
| 32 </div> |
| 33 <section id="source-language-support"> |
| 34 <h2 id="source-language-support">Source language support</h2> |
| 35 <p>The currently supported languages are C and C++. The PNaCl toolchain is |
| 36 based on Clang 3.3, which fully supports C++11 and most of C11. A |
| 37 detailed status of the language support is available <a class="reference externa
l" href="http://clang.llvm.org/cxx_status.html">here</a>.</p> |
| 38 <p>For information on using languages other than C/C++, see the <a class="refere
nce internal" href="/native-client/faq.html#other-languages"><em>FAQ |
| 39 section on other languages</em></a>.</p> |
| 40 <p>As for the standard libraries, the PNaCl toolchain is currently based on |
| 41 <code>libc++</code>, and the <code>newlib</code> standard C library (version is
available |
| 42 through the macro <code>NEWLIB_VERSION</code>). <code>libstdc++</code> is also s
upported |
| 43 but its use is discouraged; see <a class="reference internal" href="/native-clie
nt/devguide/devcycle/building.html#building-cpp-libraries"><em>C++ standard libr
aries</em></a> for more |
| 44 details.</p> |
| 45 <section id="preprocessor-definitions"> |
| 46 <h3 id="preprocessor-definitions">Preprocessor definitions</h3> |
| 47 <p>When compiling C/C++ code, the PNaCl toolchain defines the <code>__pnacl__</c
ode> |
| 48 macro. In addition, <code>__native_client__</code> is defined for compatibility |
| 49 with other NaCl toolchains.</p> |
| 50 </section></section><section id="memory-model-and-atomics"> |
| 51 <span id="id1"></span><h2 id="memory-model-and-atomics"><span id="id1"></span>Me
mory Model and Atomics</h2> |
| 52 <section id="memory-model-for-concurrent-operations"> |
| 53 <h3 id="memory-model-for-concurrent-operations">Memory Model for Concurrent Oper
ations</h3> |
| 54 <p>The memory model offered by PNaCl relies on the same coding guidelines |
| 55 as the C11/C++11 one: concurrent accesses must always occur through |
| 56 atomic primitives (offered by <a class="reference external" href="PNaClLangRef.h
tml#atomicintrinsics">atomic intrinsics</a>), and these accesses must always |
| 57 occur with the same size for the same memory location. Visibility of |
| 58 stores is provided on a happens-before basis that relates memory |
| 59 locations to each other as the C11/C++11 standards do.</p> |
| 60 <p>Non-atomic memory accesses may be reordered, separated, elided or fused |
| 61 according to C and C++’s memory model before the pexe is created as well |
| 62 as after its creation.</p> |
| 63 <p>As in C11/C++11 some atomic accesses may be implemented with locks on |
| 64 certain platforms. The <code>ATOMIC_*_LOCK_FREE</code> macros will always be |
| 65 <code>1</code>, signifying that all types are sometimes lock-free. The |
| 66 <code>is_lock_free</code> methods and <code>atomic_is_lock_free</code> will retu
rn the |
| 67 current platform’s implementation at translation time. These macros, |
| 68 methods and functions are in the C11 header <code><stdatomic.h></code> and
the |
| 69 C++11 header <code><atomic></code>.</p> |
| 70 <p>The PNaCl toolchain supports concurrent memory accesses through legacy |
| 71 GCC-style <code>__sync_*</code> builtins, as well as through C11/C++11 atomic |
| 72 primitives and the underlying <a class="reference external" href="http://gcc.gnu
.org/wiki/Atomic/GCCMM">GCCMM</a> <code>__atomic_*</code> |
| 73 primitives. <code>volatile</code> memory accesses can also be used, though these |
| 74 are discouraged. See <a class="reference internal" href="#volatile-memory-access
es">Volatile Memory Accesses</a>.</p> |
| 75 <p>PNaCl supports concurrency and parallelism with some restrictions:</p> |
| 76 <ul class="small-gap"> |
| 77 <li>Threading is explicitly supported and has no restrictions over what |
| 78 prevalent implementations offer. See <a class="reference internal" href="#thread
ing">Threading</a>.</li> |
| 79 <li><code>volatile</code> and atomic operations are address-free (operations on
the |
| 80 same memory location via two different addresses work atomically), as |
| 81 intended by the C11/C++11 standards. This is critical in supporting |
| 82 synchronous “external modifications” such as mapping underlying memo
ry |
| 83 at multiple locations.</li> |
| 84 <li>Inter-process communication through shared memory is currently not |
| 85 supported. See <a class="reference internal" href="#future-directions">Future Di
rections</a>.</li> |
| 86 <li>Signal handling isn’t supported, PNaCl therefore promotes all |
| 87 primitives to cross-thread (instead of single-thread). This may change |
| 88 at a later date. Note that using atomic operations which aren’t |
| 89 lock-free may lead to deadlocks when handling asynchronous |
| 90 signals. See <a class="reference internal" href="#future-directions">Future Dire
ctions</a>.</li> |
| 91 <li>Direct interaction with device memory isn’t supported, and there is no |
| 92 intent to support it. The embedding sandbox’s runtime can offer APIs |
| 93 to indirectly access devices.</li> |
| 94 </ul> |
| 95 <p>Setting up the above mechanisms requires assistance from the embedding |
| 96 sandbox’s runtime (e.g. NaCl’s Pepper APIs), but using them once set
up |
| 97 can be done through regular C/C++ code.</p> |
| 98 </section><section id="atomic-memory-ordering-constraints"> |
| 99 <h3 id="atomic-memory-ordering-constraints">Atomic Memory Ordering Constraints</
h3> |
| 100 <p>Atomics follow the same ordering constraints as in regular C11/C++11, |
| 101 but all accesses are promoted to sequential consistency (the strongest |
| 102 memory ordering) at pexe creation time. We plan to support more of the |
| 103 C11/C++11 memory orderings in the future.</p> |
| 104 <p>Some additional restrictions, following the C11/C++11 standards:</p> |
| 105 <ul class="small-gap"> |
| 106 <li>Atomic accesses must at least be naturally aligned.</li> |
| 107 <li>Some accesses may not actually be atomic on certain platforms, |
| 108 requiring an implementation that uses global locks.</li> |
| 109 <li>An atomic memory location must always be accessed with atomic |
| 110 primitives, and these primitives must always be of the same bit size |
| 111 for that location.</li> |
| 112 <li>Not all memory orderings are valid for all atomic operations.</li> |
| 113 </ul> |
| 114 </section><section id="volatile-memory-accesses"> |
| 115 <h3 id="volatile-memory-accesses">Volatile Memory Accesses</h3> |
| 116 <p>The C11/C++11 standards mandate that <code>volatile</code> accesses execute i
n |
| 117 program order (but are not fences, so other memory operations can |
| 118 reorder around them), are not necessarily atomic, and can’t be |
| 119 elided. They can be separated into smaller width accesses.</p> |
| 120 <p>Before any optimizations occur, the PNaCl toolchain transforms |
| 121 <code>volatile</code> loads and stores into sequentially consistent <code>volati
le</code> |
| 122 atomic loads and stores, and applies regular compiler optimizations |
| 123 along the above guidelines. This orders <code>volatiles</code> according to the |
| 124 atomic rules, and means that fences (including <code>__sync_synchronize</code>) |
| 125 act in a better-defined manner. Regular memory accesses still do not |
| 126 have ordering guarantees with <code>volatile</code> and atomic accesses, though |
| 127 the internal representation of <code>__sync_synchronize</code> attempts to |
| 128 prevent reordering of memory accesses to objects which may escape.</p> |
| 129 <p>Relaxed ordering could be used instead, but for the first release it is |
| 130 more conservative to apply sequential consistency. Future releases may |
| 131 change what happens at compile-time, but already-released pexes will |
| 132 continue using sequential consistency.</p> |
| 133 <p>The PNaCl toolchain also requires that <code>volatile</code> accesses be at l
east |
| 134 naturally aligned, and tries to guarantee this alignment.</p> |
| 135 <p>The above guarantees ease the support of legacy (i.e. non-C11/C++11) |
| 136 code, and combined with builtin fences these programs can do meaningful |
| 137 cross-thread communication without changing code. They also better |
| 138 reflect the original code’s intent and guarantee better portability.</p> |
| 139 </section></section><section id="threading"> |
| 140 <span id="language-support-threading"></span><h2 id="threading"><span id="langua
ge-support-threading"></span>Threading</h2> |
| 141 <p>Threading is explicitly supported through C11/C++11’s threading |
| 142 libraries as well as POSIX threads.</p> |
| 143 <p>Communication between threads should use atomic primitives as described |
| 144 in <a class="reference internal" href="#id1">Memory Model and Atomics</a>.</p> |
| 145 </section><section id="setjmp-and-longjmp"> |
| 146 <h2 id="setjmp-and-longjmp"><code>setjmp</code> and <code>longjmp</code></h2> |
| 147 <p>PNaCl and NaCl support <code>setjmp</code> and <code>longjmp</code> without a
ny |
| 148 restrictions beyond C’s.</p> |
| 149 </section><section id="c-exception-handling"> |
| 150 <h2 id="c-exception-handling">C++ Exception Handling</h2> |
| 151 <p>PNaCl currently supports C++ exception handling through <code>setjmp()</code>
and |
| 152 <code>longjmp()</code>, which can be enabled with the <code>--pnacl-exceptions=s
jlj</code> |
| 153 linker flag. Exceptions are disabled by default so that faster and |
| 154 smaller code is generated, and <code>throw</code> statements are replaced with |
| 155 calls to <code>abort()</code>. The usual <code>-fno-exceptions</code> flag is al
so |
| 156 supported. PNaCl will support full zero-cost exception handling in the |
| 157 future.</p> |
| 158 <p>NaCl supports full zero-cost C++ exception handling.</p> |
| 159 </section><section id="inline-assembly"> |
| 160 <h2 id="inline-assembly">Inline Assembly</h2> |
| 161 <p>Inline assembly isn’t supported by PNaCl because it isn’t portabl
e. The |
| 162 one current exception is the common compiler barrier idiom |
| 163 <code>asm("":::"memory")</code>, which gets transformed to a
sequentially |
| 164 consistent memory barrier (equivalent to <code>__sync_synchronize()</code>). In |
| 165 PNaCl this barrier is only guaranteed to order <code>volatile</code> and atomic |
| 166 memory accesses, though in practice the implementation attempts to also |
| 167 prevent reordering of memory accesses to objects which may escape.</p> |
| 168 <p>NaCl supports a fairly wide subset of inline assembly through GCC’s |
| 169 inline assembly syntax, with the restriction that the sandboxing model |
| 170 for the target architecture has to be respected.</p> |
| 171 </section><section id="future-directions"> |
| 172 <h2 id="future-directions">Future Directions</h2> |
| 173 <section id="simd"> |
| 174 <h3 id="simd">SIMD</h3> |
| 175 <p>PNaCl currently doesn’t support SIMD. We plan to add SIMD support in th
e |
| 176 very near future.</p> |
| 177 <p>NaCl supports SIMD.</p> |
| 178 </section><section id="inter-process-communication"> |
| 179 <h3 id="inter-process-communication">Inter-Process Communication</h3> |
| 180 <p>Inter-process communication through shared memory is currently not |
| 181 supported by PNaCl/NaCl. When implemented, it may be limited to |
| 182 operations which are lock-free on the current platform (<code>is_lock_free</code
> |
| 183 methods). It will rely on the address-free properly discussed in <a class="refer
ence internal" href="#memory-model-for-concurrent-operations">Memory |
| 184 Model for Concurrent Operations</a>.</p> |
| 185 </section><section id="posix-style-signal-handling"> |
| 186 <h3 id="posix-style-signal-handling">POSIX-style Signal Handling</h3> |
| 187 <p>POSIX-style signal handling really consists of two different features:</p> |
| 188 <ul class="small-gap"> |
| 189 <li><p class="first"><strong>Hardware exception handling</strong> (synchronous s
ignals): The ability |
| 190 to catch hardware exceptions (such as memory access faults and |
| 191 division by zero) using a signal handler.</p> |
| 192 <p>PNaCl currently doesn’t support hardware exception handling.</p> |
| 193 <p>NaCl supports hardware exception handling via the |
| 194 <code><nacl/nacl_exception.h></code> interface.</p> |
| 195 </li> |
| 196 <li><p class="first"><strong>Asynchronous interruption of threads</strong> (asyn
chronous signals): The |
| 197 ability to asynchronously interrupt the execution of a thread, |
| 198 forcing the thread to run a signal handler.</p> |
| 199 <p>A similar feature is <strong>thread suspension</strong>: The ability to |
| 200 asynchronously suspend and resume a thread and inspect or modify its |
| 201 execution state (such as register state).</p> |
| 202 <p>Neither PNaCl nor NaCl currently support asynchronous interruption |
| 203 or suspension of threads.</p> |
| 204 </li> |
| 205 </ul> |
| 206 <p>If PNaCl were to support either of these, the interaction of |
| 207 <code>volatile</code> and atomics with same-thread signal handling would need |
| 208 to be carefully detailed.</p> |
| 209 </section><section id="computed-goto"> |
| 210 <h3 id="computed-goto">Computed <code>goto</code></h3> |
| 211 <p>PNaCl currently doesn’t support computed <code>goto</code>, a non-stand
ard |
| 212 extension to C used by some interpreters.</p> |
| 213 <p>NaCl supports computed <code>goto</code>.</p> |
| 214 </section></section></section> |
| 215 |
| 216 {{/partials.standard_nacl_article}} |
| OLD | NEW |
|---|
Chromium Code Reviews
Issue 140993006:
[NaCl SDK Docs] Check in the generated NaCl SDK Documentation. (Closed)
Base URL: svn://svn.chromium.org/chrome/trunk/src