PATCH: back at you

[Loren James Rittle]

In article <20030425232522.GA26052@disaster.jaj.com>,
Phil Edwards<phil@jaj.com> writes:

>> * configure.target (athlon, i586+): Add i486 to list to use cpu/i486.
>> (i386): New case.

> None of these three need to be listed.  :-)  The 'DEFAULTS' clause, just
> above where you edited, takes care of i486.  i386 doesn't need an entry
> either, for the same reason:  <cpu> will default to config/cpu/<cpu>.

Thank you for the critical review.  Yup, the i386 code path is indeed
found after I removed the above patch from my working tree.  I am
testing what I posted on Friday (i.e. the tweak of Joel's patch).  It
would be sweet if Joel found a reasonable, portable (>=i386) code
segment to use before the 3.3 release.  I will document the speed
regression for as-configured-i386-yet-really-i686 with and without the
patch in order to justify it.  The fact of the matter is that we are
changing the effective ABI for this machine between 3.2 and 3.3.  I
think we would all rather jump from code broken for i386 to tuned code
that works for i386 instead of using generic mutex, if possible and
with little risk.

> Also, athlon* doesn't need an entry.  [...] Likewise for k6 and
> other "aliases".

OK, but I'm not touching it (under the "ain't broke, don't fix" rule ;-).

>> * config/cpu/i386/atomicity.h: New file.

> I'm not qualified to review that part, but a brief look didn't show anything
> obviously wrong.

I am qualified to review it; however it is the sort of change that
needs multiple pairs of qualified eyes (cite plan 9 paper on topic).
I do have minor concerns about XCHG in loop verses `LOCK; XADD' given
the behavior change (XADD must complete in a known number of CPU
cycles; whereas XCHG is a true spinlock w/o sleep/yield - this
behavior will stink in some cases).  I also have a concern about using
a shared lock for all memory locations (however, we do that for some
other CPUs; however, I see how to possibly address this concern using
a template trick).

Regards,
Loren