This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support for i386 builds of glibc?
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library<libc-alpha at sourceware dot org>
- Date: Mon, 4 Mar 2013 20:56:08 +0000
- Subject: Re: Support for i386 builds of glibc?
- References: <5134DD1D.7090906@redhat.com> <20130304191059.862FF2C0A3@topped-with-meat.com>
On Mon, 4 Mar 2013, Roland McGrath wrote:
> of NPTL. AIUI i386 per se supports exactly one SMP-safe operation, which
> is xchg. Reworking everything to work with just that is conceivable, but
> it doesn't seem worth the effort.
Not really, x86 has supported SMP-safe atomic ops for all ALU operations
doing RMW on memory since the 8086, e.g. ADD, SUB, XOR, etc. A LOCK
instruction prefix is required for atomicity; it's implied for XCHG.
It's just that the i386 does not support the two new operations used by
some code the i486 added: CMPXCHG and XADD. They could be easily emulated
with the aid of global spinlocks, but given the decline of the i386 it's
probably not worth the effort.
Moreover, especially as no i386 SMP system has ever been supported by
Linux, these instructions could instead be emulated in the undefined
opcode exception handler by the kernel just like we do these days for
atomic LL and SC instructions that are missing from the first ISA revision
of MIPS processors. The benefit would be no special user binaries would
have to be used for i386 systems (another instruction that would have to
be emulated is BSWAP; that would cover the whole i486 user ISA extension
beyond the i386, three instructions total). If Linux still supported the
i386, that is.
Maciej