</li>
</ul>
-</div><section id="source-language-support">
-<h2 id="source-language-support">Source language support</h2>
+</div><h2 id="source-language-support">Source language support</h2>
<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>
-<section id="versions">
<h3 id="versions">Versions</h3>
<p>Version information can be obtained:</p>
<ul class="small-gap">
<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>
-</section><section id="preprocessor-definitions">
<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
<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>
-</section><section id="atomic-memory-ordering-constraints">
<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
for that location.</li>
<li>Not all memory orderings are valid for all atomic operations.</li>
</ul>
-</section><section id="volatile-memory-accesses">
<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>
-</section></section><section id="threading">
-<span id="language-support-threading"></span><h2 id="threading"><span id="language-support-threading"></span>Threading</h2>
+<h2 id="threading"><span id="language-support-threading"></span>Threading</h2>
<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>
-</section><section id="setjmp-and-longjmp">
<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>
-</section><section id="c-exception-handling">
-<h2 id="c-exception-handling">C++ Exception Handling</h2>
+<h2 id="c-exception-handling"><span id="exception-handling"></span>C++ Exception Handling</h2>
<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>
-</section><section id="inline-assembly">
<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>
-</section><section id="portable-simd-vectors">
-<span id="id2"></span><h2 id="portable-simd-vectors"><span id="id2"></span>Portable SIMD Vectors</h2>
+<h2 id="portable-simd-vectors"><span id="id2"></span>Portable SIMD Vectors</h2>
<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
return ret;
}
</pre>
-<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>
<table border="1" class="docutils">
<colgroup>
</colgroup>
<tr class="row-odd"><th class="head">Type</th>
<th class="head">Num Elements</th>
<th class="head">Vector Bit Width</th>
+<th class="head">Expected Bit Alignment</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td><code>uint8_t</code></td>
<td>16</td>
<td>128</td>
+<td>8</td>
</tr>
<tr class="row-odd"><td><code>int8_t</code></td>
<td>16</td>
<td>128</td>
+<td>8</td>
</tr>
<tr class="row-even"><td><code>uint16_t</code></td>
<td>8</td>
<td>128</td>
+<td>16</td>
</tr>
<tr class="row-odd"><td><code>int16_t</code></td>
<td>8</td>
<td>128</td>
+<td>16</td>
</tr>
<tr class="row-even"><td><code>uint32_t</code></td>
<td>4</td>
<td>128</td>
+<td>32</td>
</tr>
<tr class="row-odd"><td><code>int32_t</code></td>
<td>4</td>
<td>128</td>
+<td>32</td>
</tr>
<tr class="row-even"><td><code>float</code></td>
<td>4</td>
<td>128</td>
+<td>32</td>
</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>
<p>The following operators are supported on vectors:</p>
<table border="1" class="docutils">
<colgroup>
return shift_me >> __builtin_shuffle_vector(tmp, tmp, 0, 0, 0, 0);
}
</pre>
-</section><section id="auto-vectorization">
<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>
-</section></section><section id="undefined-behavior">
<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>
-</section><section id="floating-point">
<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>
</ul>
</li>
</ul>
-</section><section id="computed-goto">
<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>
-</section><section id="future-directions">
<h2 id="future-directions">Future Directions</h2>
-<section id="inter-process-communication">
<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>
-</section><section id="posix-style-signal-handling">
<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>
-</section></section></section>
+</section>
{{/partials.standard_nacl_article}}
projects / platform / framework / web / crosswalk.git / blobdiff