Re: Support for Intel X1000

[Rich Felker <dalias at libc dot org>]

On Tue, May 12, 2015 at 04:38:04PM +0200, Florian Weimer wrote:
> On 05/12/2015 12:28 PM, Kinsella, Ray wrote:
> 
> > 1. Not using the LOCK prefix on the Intel X1000.  This can be achieved 
> > either by defining UP (uniprocessor) or telling the assembler to omit
> > the LOCK prefix "momit-lock-prefix=yes". 
> 
> We might have places where the instruction layout matters (not sure
> about that).  It might not be as simple as flipping a compiler switch.
> 
> > 2. OS builders creating a UP version of glibc targeted for the X1000. 
> > The runtime linker then decides which glibc to load based on a HWCAP, 
> > in a similar way to how the Xen specific glibc is loaded.
> 
> I think the two cases are not really comparable.  Back in those days,
> access to thread-local variables was pretty rare and mostly restricted
> to glibc.
> 
> Nowadays, you'd have to recompile a whole distribution to get rid of
> atomics everywhere, and I can't really see any of the major
> distributions doing that.

Not only that, but the code would not be working. In the kernel,
defining UP and disabling lock prefix is sufficient because the kernel
controls scheduling and interrupt masking and therefore doesn't need
atomics except for synchronizing with other physical cores. In
userspace, any multi-threaded program absolutely needs atomics for
correct behavior, even without explicit lock usage. As far as I can
tell this CPU is just completely unusable unless there workaround. If
it's possible for a microcode update to make the LOCK prefix generate
an illegal instruction exception, emulating the prefixed instruction
in the kernel would suffice, albeit at a ridiculous cost.

Rich