gcc 4.1 implements compiler builtins for atomic ops

Ulrich Drepper drepper@redhat.com
Mon Jun 27 00:54:00 GMT 2005


David S. Miller wrote:

> If, as a not-so-hypothetical example, some years from now the
> Pentium-1000 has some subtle atomic operation bug that needs a proper
> workaround,

In this case, what would happen is that you update the microcode and the
processor should behave correctly again.

But the real problem with your argumentation is that there is no reason
why the locking code should have a higher probability of defects in the
processor than all the other parts combined.  Hence to help with
processor bugs we must not ever generate any asm code again (for
application).  Only byte code since then we only have to replace the
interpreter.

The ppc405 problem is not a minority issue with ppc again the rest.
It's even a problem in ppc405 against ppc all-the-others.  It's some
obscure embedded thing (these days).  You compile special software
stacks for it.  There is no real mixing with the "real" ppc code.  I.e.,
adding an indirection layer for just this cause is a punishment even for
almost all ppc users.

Not generating the code in the compiler means that people who are mainly
interested in the architectures with easy use of atomic operations look
at the code and think we on earth they should pay such a high price for
the operation if they can do it much cheaper when inlining the code.  It
is not me saying that this is what should happen.  It is what will
happen regardless of my opinion.  The result is reduced portability of
sources and, as I said before, the archs with the diverging APIs will
suffer.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20050627/3c24f2d2/attachment.sig>


More information about the Libc-alpha mailing list