linux-mips
[Top] [All Lists]

Re: MIPS_ATOMIC_SET again (Re: newest kernel

To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel
From: "Kevin D. Kissell" <kevink@mips.com>
Date: Thu, 24 May 2001 01:49:17 +0200
Cc: "Joe deBlaquiere" <jadb@redhat.com>, <linux-mips@oss.sgi.com>
References: <Pine.GSO.3.96.1010523212941.16787A-100000@delta.ds2.pg.gda.pl>
Sender: owner-linux-mips@oss.sgi.com
> > parts, the latter is more efficient for contemporary parts.  Those
> > of us who work on recent and future designs will always tend
> > to favor the latter - what's the point of using MIPS32/MIPS64
> > and beyond CPUs if gnu/Linux binaries are going to treat them
> > like R3000s?
> 
>  If you work on new processors only, then there is no problem.  You
> configure your tools to build binaries for systems you use and you'll
> never see R3k compatibility code.
> 
>  Please do yourself a favor and look at the relevant part of glibc.  If
> you build glibc (and any other other program that makes use of
> _test_and_set()) for ISA II+, the code gets actually inlined with ll/sc
> used as expected.
> 
>  So the problem is?

The problem is that, out in industry, not everyone wants to
build their entire userland from source, and nobody particularly 
wants to deal with  the product management problems of making, 
maintaining,  testing, and distributing all the permutations of BE/LE, 
FP/noFP, LLSC/noLLSC, etc, etc.

            Kevin K.



<Prev in Thread] Current Thread [Next in Thread>