<p>The currently supported languages are C and C++. The PNaCl toolchain is
based on recent Clang, which fully supports C++11 and most of C11. A
detailed status of the language support is available <a class="reference external" href="http://clang.llvm.org/cxx_status.html">here</a>.</p>
<p>The currently supported languages are C and C++. The PNaCl toolchain is
based on recent Clang, which fully supports C++11 and most of C11. A
detailed status of the language support is available <a class="reference external" href="http://clang.llvm.org/cxx_status.html">here</a>.</p>
<code>libc++</code>, and the <code>newlib</code> standard C library. <code>libstdc++</code> is also
supported but its use is discouraged; see <a class="reference internal" href="/native-client/devguide/devcycle/building.html#building-cpp-libraries"><em>C++ standard libraries</em></a>
for more details.</p>
<code>libc++</code>, and the <code>newlib</code> standard C library. <code>libstdc++</code> is also
supported but its use is discouraged; see <a class="reference internal" href="/native-client/devguide/devcycle/building.html#building-cpp-libraries"><em>C++ standard libraries</em></a>
for more details.</p>
<li><code>libc++</code>: use the <code>_LIBCPP_VERSION</code> macro.</li>
<li><code>libstdc++</code>: use the <code>_GLIBCXX_VERSION</code> macro.</li>
</ul>
<li><code>libc++</code>: use the <code>_LIBCPP_VERSION</code> macro.</li>
<li><code>libstdc++</code>: use the <code>_GLIBCXX_VERSION</code> macro.</li>
</ul>
<h3 id="preprocessor-definitions">Preprocessor definitions</h3>
<p>When compiling C/C++ code, the PNaCl toolchain defines the <code>__pnacl__</code>
macro. In addition, <code>__native_client__</code> is defined for compatibility
with other NaCl toolchains.</p>
<h3 id="preprocessor-definitions">Preprocessor definitions</h3>
<p>When compiling C/C++ code, the PNaCl toolchain defines the <code>__pnacl__</code>
macro. In addition, <code>__native_client__</code> is defined for compatibility
with other NaCl toolchains.</p>
-</section></section><section id="memory-model-and-atomics">
-<span id="id1"></span><h2 id="memory-model-and-atomics"><span id="id1"></span>Memory Model and Atomics</h2>
-<section id="memory-model-for-concurrent-operations">
+<h2 id="memory-model-and-atomics"><span id="id1"></span>Memory Model and Atomics</h2>
<h3 id="memory-model-for-concurrent-operations">Memory Model for Concurrent Operations</h3>
<p>The memory model offered by PNaCl relies on the same coding guidelines
as the C11/C++11 one: concurrent accesses must always occur through
<h3 id="memory-model-for-concurrent-operations">Memory Model for Concurrent Operations</h3>
<p>The memory model offered by PNaCl relies on the same coding guidelines
as the C11/C++11 one: concurrent accesses must always occur through
<p>Setting up the above mechanisms requires assistance from the embedding
sandbox’s runtime (e.g. NaCl’s Pepper APIs), but using them once setup
can be done through regular C/C++ code.</p>
<p>Setting up the above mechanisms requires assistance from the embedding
sandbox’s runtime (e.g. NaCl’s Pepper APIs), but using them once setup
can be done through regular C/C++ code.</p>
<h3 id="atomic-memory-ordering-constraints">Atomic Memory Ordering Constraints</h3>
<p>Atomics follow the same ordering constraints as in regular C11/C++11,
but all accesses are promoted to sequential consistency (the strongest
<h3 id="atomic-memory-ordering-constraints">Atomic Memory Ordering Constraints</h3>
<p>Atomics follow the same ordering constraints as in regular C11/C++11,
but all accesses are promoted to sequential consistency (the strongest
<h3 id="volatile-memory-accesses">Volatile Memory Accesses</h3>
<p>The C11/C++11 standards mandate that <code>volatile</code> accesses execute in
program order (but are not fences, so other memory operations can
<h3 id="volatile-memory-accesses">Volatile Memory Accesses</h3>
<p>The C11/C++11 standards mandate that <code>volatile</code> accesses execute in
program order (but are not fences, so other memory operations can
code, and combined with builtin fences these programs can do meaningful
cross-thread communication without changing code. They also better
reflect the original code’s intent and guarantee better portability.</p>
code, and combined with builtin fences these programs can do meaningful
cross-thread communication without changing code. They also better
reflect the original code’s intent and guarantee better portability.</p>
<p>Threading is explicitly supported through C11/C++11’s threading
libraries as well as POSIX threads.</p>
<p>Communication between threads should use atomic primitives as described
in <a class="reference internal" href="#id1">Memory Model and Atomics</a>.</p>
<p>Threading is explicitly supported through C11/C++11’s threading
libraries as well as POSIX threads.</p>
<p>Communication between threads should use atomic primitives as described
in <a class="reference internal" href="#id1">Memory Model and Atomics</a>.</p>
<h2 id="setjmp-and-longjmp"><code>setjmp</code> and <code>longjmp</code></h2>
<p>PNaCl and NaCl support <code>setjmp</code> and <code>longjmp</code> without any
restrictions beyond C’s.</p>
<h2 id="setjmp-and-longjmp"><code>setjmp</code> and <code>longjmp</code></h2>
<p>PNaCl and NaCl support <code>setjmp</code> and <code>longjmp</code> without any
restrictions beyond C’s.</p>
<p>PNaCl currently supports C++ exception handling through <code>setjmp()</code> and
<code>longjmp()</code>, which can be enabled with the <code>--pnacl-exceptions=sjlj</code>
linker flag. Exceptions are disabled by default so that faster and
<p>PNaCl currently supports C++ exception handling through <code>setjmp()</code> and
<code>longjmp()</code>, which can be enabled with the <code>--pnacl-exceptions=sjlj</code>
linker flag. Exceptions are disabled by default so that faster and
supported. PNaCl will support full zero-cost exception handling in the
future.</p>
<p>NaCl supports full zero-cost C++ exception handling.</p>
supported. PNaCl will support full zero-cost exception handling in the
future.</p>
<p>NaCl supports full zero-cost C++ exception handling.</p>
<h2 id="inline-assembly">Inline Assembly</h2>
<p>Inline assembly isn’t supported by PNaCl because it isn’t portable. The
one current exception is the common compiler barrier idiom
<h2 id="inline-assembly">Inline Assembly</h2>
<p>Inline assembly isn’t supported by PNaCl because it isn’t portable. The
one current exception is the common compiler barrier idiom
<p>NaCl supports a fairly wide subset of inline assembly through GCC’s
inline assembly syntax, with the restriction that the sandboxing model
for the target architecture has to be respected.</p>
<p>NaCl supports a fairly wide subset of inline assembly through GCC’s
inline assembly syntax, with the restriction that the sandboxing model
for the target architecture has to be respected.</p>
<p>SIMD vectors aren’t part of the C/C++ standards and are traditionally
very hardware-specific. Portable Native Client offers a portable version
of SIMD vector datatypes and operations which map well to modern
architectures and offer performance which matches or approaches
hardware-specific uses.</p>
<p>SIMD vectors aren’t part of the C/C++ standards and are traditionally
very hardware-specific. Portable Native Client offers a portable version
of SIMD vector datatypes and operations which map well to modern
architectures and offer performance which matches or approaches
hardware-specific uses.</p>
-<p>SIMD vector support was added to Portable Native Client for version 37
-of Chrome and more features, including performance enhancements, are
-expected to be added in subsequent releases.</p>
-<section id="hand-coding-vector-extensions">
+<p>SIMD vector support was added to Portable Native Client for version 37 of Chrome
+and more features, including performance enhancements, have been added in
+subsequent releases, see the <a class="reference internal" href="/native-client/sdk/release-notes.html#sdk-release-notes"><em>Release Notes</em></a> for more
+details.</p>
<h3 id="hand-coding-vector-extensions">Hand-Coding Vector Extensions</h3>
<p>The initial vector support in Portable Native Client adds <a class="reference external" href="http://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors">LLVM vectors</a>
and <a class="reference external" href="http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html">GCC vectors</a> since these
<h3 id="hand-coding-vector-extensions">Hand-Coding Vector Extensions</h3>
<p>The initial vector support in Portable Native Client adds <a class="reference external" href="http://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors">LLVM vectors</a>
and <a class="reference external" href="http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html">GCC vectors</a> since these
-<p>Vector datatypes are currently expected to be 128-bit wide with one of
-the following element types:</p>
+<p>Vector datatypes are currently expected to be 128-bit wide with one of the
+following element types, and they’re expected to be aligned to the underlying
+element’s bit width (loads and store will otherwise be broken up into scalar
+accesses to prevent faults):</p>
<tr class="row-odd"><th class="head">Type</th>
<th class="head">Num Elements</th>
<th class="head">Vector Bit Width</th>
<tr class="row-odd"><th class="head">Type</th>
<th class="head">Num Elements</th>
<th class="head">Vector Bit Width</th>
</tr>
</tbody>
</table>
<p>64-bit integers and double-precision floating point will be supported in
a future release, as will 256-bit and 512-bit vectors.</p>
</tr>
</tbody>
</table>
<p>64-bit integers and double-precision floating point will be supported in
a future release, as will 256-bit and 512-bit vectors.</p>
+<p>Vector element bit width alignment can be stated explicitly (this is assumed by
+PNaCl, but not necessarily by other compilers), and smaller alignments can also
+be specified:</p>
+<pre class="prettyprint">
+typedef int v4s_element __attribute__((vector_size(16), aligned(4)));
+typedef int v4s_unaligned __attribute__((vector_size(16), aligned(1)));
+</pre>
return shift_me >> __builtin_shuffle_vector(tmp, tmp, 0, 0, 0, 0);
}
</pre>
return shift_me >> __builtin_shuffle_vector(tmp, tmp, 0, 0, 0, 0);
}
</pre>
<h3 id="auto-vectorization">Auto-Vectorization</h3>
<p>Auto-vectorization is currently not enabled for Portable Native Client,
but will be in a future release.</p>
<h3 id="auto-vectorization">Auto-Vectorization</h3>
<p>Auto-vectorization is currently not enabled for Portable Native Client,
but will be in a future release.</p>
<h2 id="undefined-behavior">Undefined Behavior</h2>
<p>The C and C++ languages expose some undefined behavior which is
discussed in <a class="reference internal" href="/native-client/reference/pnacl-undefined-behavior.html#undefined-behavior"><em>PNaCl Undefined Behavior</em></a>.</p>
<h2 id="undefined-behavior">Undefined Behavior</h2>
<p>The C and C++ languages expose some undefined behavior which is
discussed in <a class="reference internal" href="/native-client/reference/pnacl-undefined-behavior.html#undefined-behavior"><em>PNaCl Undefined Behavior</em></a>.</p>
<h2 id="floating-point">Floating-Point</h2>
<p>PNaCl exposes 32-bit and 64-bit floating point operations which are
mostly IEEE-754 compliant. There are a few caveats:</p>
<h2 id="floating-point">Floating-Point</h2>
<p>PNaCl exposes 32-bit and 64-bit floating point operations which are
mostly IEEE-754 compliant. There are a few caveats:</p>
<h2 id="computed-goto">Computed <code>goto</code></h2>
<p>PNaCl supports computed <code>goto</code>, a non-standard GCC extension to C used
by some interpreters, by lowering them to <code>switch</code> statements. The
<h2 id="computed-goto">Computed <code>goto</code></h2>
<p>PNaCl supports computed <code>goto</code>, a non-standard GCC extension to C used
by some interpreters, by lowering them to <code>switch</code> statements. The
program will run faster with the option turned off (e.g., if the program
does extra work to take advantage of computed <code>goto</code>).</p>
<p>NaCl supports computed <code>goto</code> without any transformation.</p>
program will run faster with the option turned off (e.g., if the program
does extra work to take advantage of computed <code>goto</code>).</p>
<p>NaCl supports computed <code>goto</code> without any transformation.</p>
<h3 id="inter-process-communication">Inter-Process Communication</h3>
<p>Inter-process communication through shared memory is currently not
supported by PNaCl/NaCl. When implemented, it may be limited to
operations which are lock-free on the current platform (<code>is_lock_free</code>
methods). It will rely on the address-free properly discussed in <a class="reference internal" href="#memory-model-for-concurrent-operations">Memory
Model for Concurrent Operations</a>.</p>
<h3 id="inter-process-communication">Inter-Process Communication</h3>
<p>Inter-process communication through shared memory is currently not
supported by PNaCl/NaCl. When implemented, it may be limited to
operations which are lock-free on the current platform (<code>is_lock_free</code>
methods). It will rely on the address-free properly discussed in <a class="reference internal" href="#memory-model-for-concurrent-operations">Memory
Model for Concurrent Operations</a>.</p>
<h3 id="posix-style-signal-handling">POSIX-style Signal Handling</h3>
<p>POSIX-style signal handling really consists of two different features:</p>
<ul class="small-gap">
<h3 id="posix-style-signal-handling">POSIX-style Signal Handling</h3>
<p>POSIX-style signal handling really consists of two different features:</p>
<ul class="small-gap">
<p>If PNaCl were to support either of these, the interaction of
<code>volatile</code> and atomics with same-thread signal handling would need
to be carefully detailed.</p>
<p>If PNaCl were to support either of these, the interaction of
<code>volatile</code> and atomics with same-thread signal handling would need
to be carefully detailed.</p>