<table>
<tbody>
<tr class="odd">
<td align="left">Doc. No.:</td>
<td align="left">P1258R0</td>
</tr>
<tr class="even">
<td align="left">Date:</td>
<td align="left">2018-10-08</td>
</tr>
<tr class="odd">
<td align="left">Reply to:</td>
<td align="left">Detlef Vollmann, dv@vollmann.ch</td>
</tr>
<tr class="even">
<td align="left">Audience:</td>
<td align="left">SG1, LEWG, WG21</td>
</tr>
</tbody>
</table>
<h1 id="dont-make-c-unimplementable-on-small-cpus">Don't Make C++ Unimplementable On Small CPUs</h1>
<p>Freestanding implementations were originally introduced to provide a language only implementation plus &quot;certain language-support libraries&quot; for small systems that don't have and don't need an underlying operating system.</p>
<p>This allows vendors to provide a &quot;compiler-only&quot; implementation of C++ for such systems.</p>
<p>At the Rapperwil meeting SG1 and LEWG decided to make at least one lock-free atomic integer type mandatory even in freestanding implementations. This requires that there's a lock-free <code>compare_exchange</code>. Implementing such a type on CPU architectures that don't provide a respective machine instruction without OS support is very problematic.</p>
<p>WG21 should be very careful to just assume that modern platforms will provide such machine instructions. E.g. ARM Cortex M0 and M0+ don't provide such instructions and are pretty modern.</p>
<p>Before WG21 decides on requirements for freestanding implementations, WG21 should be very sure that the requirements really don't cause implementation issues.</p>
<p>So please come back the the decision in Rapperswil and make the lock-free atomic integer type optional again.</p>
