AMD has cmpxchg16b now - sort of
Joe Seigh
cmpxchg16b as an instruction now. Except it's a processor feature. And
it turns out cmpxchg16b is a processor feature for Intel 64 bit extensions
as well. Powerpc is looking more and more attractive.
--
Joe Seigh
Nathan J. Williams
[this seems more like a comp.arch topic than a c.p.t topic, but here
it is...]
"Joe Seigh" <jsei...@xemaps.com> writes:
> Although they introduced the new features midstream, making it an option
> probably wasn't the best way to go.
There has to be some way to tell whether the feature exists on a
processor when code is running on it. Your choices are an option bit
or a lookup table. The lookup table is going to be unmaintainable, so
an option bit is clearly the way to go
> That conbined with no external documentation on what processor
> models have what features makes it impossible to determine if the
> processor has the feature before buying it.
Is that a serious problem? For a large-scale buyer (say, building a
compute cluster where this feature will be critical), you do an
evaluation where you can test it. For an individual who wants to mess
around with atomic operations, take advantage of return policies,
third-party reviews, and the like.
> They probably should have gone with a architectural version numbering
> scheme that let you know at what point features become committed to the
> architecture.
Option bits are a pretty well entrenched mechanism for this on several
architectures (not, notably, PowerPC, where you have to have a lookup
table based on the CPU ID to find out if you have an FPU, AltiVec, or
whatnot).
- Nathan
Joe Seigh
>
> [this seems more like a comp.arch topic than a c.p.t topic, but here
> it is...]
>
> "Joe Seigh" <jsei...@xemaps.com> writes:
>
>> Although they introduced the new features midstream, making it an option
>> probably wasn't the best way to go.
>
> There has to be some way to tell whether the feature exists on a
> processor when code is running on it. Your choices are an option bit
> or a lookup table. The lookup table is going to be unmaintainable, so
> an option bit is clearly the way to go
No I meant versioning. When they add a new architectural feature,
it becomes present on every processor of a certain version or later.
That way, all you need to know when getting a processor is the version
number.
>
>> That conbined with no external documentation on what processor
>> models have what features makes it impossible to determine if the
>> processor has the feature before buying it.
>
> Is that a serious problem? For a large-scale buyer (say, building a
> compute cluster where this feature will be critical), you do an
> evaluation where you can test it. For an individual who wants to mess
> around with atomic operations, take advantage of return policies,
> third-party reviews, and the like.
It's a serious problem. Most places don't allow returns now, even in
the case of defective product. You have to return to the OEM. The
feature in question is a bit esoteric for review sites.
>
>> They probably should have gone with a architectural version numbering
>> scheme that let you know at what point features become committed to the
>> architecture.
>
> Option bits are a pretty well entrenched mechanism for this on several
> architectures (not, notably, PowerPC, where you have to have a lookup
> table based on the CPU ID to find out if you have an FPU, AltiVec, or
> whatnot).
>
The synchronization stuff for powerpc was pretty well in place from the
very beginning. You don't have to query processor features to know
if load reserved and store conditional is installed. When they do add
stuff it is usually in a backwards compatible way. Powerpc isync just
executes as sync on processors without isync. Intel has and continues to
add stuff in after the fact. You have this problem with almost every
synchronization primative there is on Intel architectures. Look at
the memory barrier instructions. You want those inline as calling an
external function would be too expensive. But that makes them statically
linked in effect, so you go with the lowest common implementation, an
interlocked instruction to be on the safe side.
--
Joe Seigh
Casper H.S. Dik
>No I meant versioning. When they add a new architectural feature,
>it becomes present on every processor of a certain version or later.
>That way, all you need to know when getting a processor is the version
>number.
And version X from competeitor A, version Y from B, version Z from C,
etc. There are four or five viable x86 CPU producers. The
version bits work much better in x86 space because of that.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Joe Seigh
> "Joe Seigh" <jsei...@xemaps.com> writes:
>
>> No I meant versioning. When they add a new architectural feature,
>> it becomes present on every processor of a certain version or later.
>> That way, all you need to know when getting a processor is the version
>> number.
>
> And version X from competeitor A, version Y from B, version Z from C,
> etc. There are four or five viable x86 CPU producers. The
> version bits work much better in x86 space because of that.
>
That's all well and fine if the feature is optional and you have a viable
workaround if the feature is not available. There isn't any workaround
for cmpxchg16b.
Not a problem in the short term since I'm switching to powerpc and keeping
my 32 bit intel system for the time being. There is no short term need to
have atomic_ptr work on x86-64 so the longer I wait the better.
--
Joe Seigh
Nathan J. Williams
> No I meant versioning. When they add a new architectural feature,
> it becomes present on every processor of a certain version or later.
> That way, all you need to know when getting a processor is the version
> number.
That means that having added feature X and then feature Y, they can't
sell something with Y but without X. Given the number of niche
markets, specialized applications, and so on, no vendor is going to
restrict themselves that way.
> > Option bits are a pretty well entrenched mechanism for this on several
> > architectures (not, notably, PowerPC, where you have to have a lookup
> > table based on the CPU ID to find out if you have an FPU, AltiVec, or
> > whatnot).
> >
> The synchronization stuff for powerpc was pretty well in place from the
> very beginning.
Synchronization, sure, but there are lots of other features one is
interested in testing and that have varied across PowerPC
implementations (FPU, SIMD/vector instructions (including, but not
limited to AltiVec), string instructions, handling unaligned data
automatically, and so on).
- Nathan
Joe Seigh
> "Joe Seigh" <jsei...@xemaps.com> writes:
>> The synchronization stuff for powerpc was pretty well in place from the
>> very beginning.
>
> Synchronization, sure, but there are lots of other features one is
> interested in testing and that have varied across PowerPC
> implementations (FPU, SIMD/vector instructions (including, but not
> limited to AltiVec), string instructions, handling unaligned data
> automatically, and so on).
>
All of those things can be simulated, albeit with a possibly significant
performance hit. Significant enough that they'd likely advertize or explicitly
document the fact. Why else go through the trouble of putting the feature in.
The synchronization stuff can't be simulated and AFAICT not documented on
Intel's or AMD's web site. Though I suppose I could email some Intel or AMD marketing
type and ask for quotes for quantities of 100000 of processors that have that
feature. :)
--
Joe Seigh
David Hopwood
> On 08 Mar 2005 09:22:43 -0500, Nathan J. Williams <nat...@mit.edu> wrote:
>
>> There has to be some way to tell whether the feature exists on a
>> processor when code is running on it. Your choices are an option bit
>> or a lookup table. The lookup table is going to be unmaintainable, so
>> an option bit is clearly the way to go
>
> No I meant versioning. When they add a new architectural feature,
> it becomes present on every processor of a certain version or later.
> That way, all you need to know when getting a processor is the version
> number.
Using a feature bit doesn't preclude specifying that the feature bit
must be set on all processors above a given version. In practice that
is the usual policy, even if it isn't written down: it's almost unheard
of for manufacturers to remove features once they have been added to a
given processor line.
>> Option bits are a pretty well entrenched mechanism for this on several
>> architectures (not, notably, PowerPC, where you have to have a lookup
>> table based on the CPU ID to find out if you have an FPU, AltiVec, or
>> whatnot).
>>
> The synchronization stuff for powerpc was pretty well in place from the
> very beginning. You don't have to query processor features to know
> if load reserved and store conditional is installed. When they do add
> stuff it is usually in a backwards compatible way. Powerpc isync just
> executes as sync on processors without isync.
Nitpick: that's forward compatibility.
--
David Hopwood <david.nosp...@blueyonder.co.uk>
Joe Seigh
> Using a feature bit doesn't preclude specifying that the feature bit
> must be set on all processors above a given version. In practice that
> is the usual policy, even if it isn't written down: it's almost unheard
> of for manufacturers to remove features once they have been added to a
> given processor line.
>
Somebody on comp.arch suggested that cmpxchg16b might not stay in Intel
x86-64. AMD probably added cmpxchg16b to stay compatible with Intel.
Things aren't chiseled in stone yet. I think you'd have to wait until the
next generation of processors to see if they start documenting it as
being present as of a certain generation like cmpxchg8b which is documented
as being i586 or later.
Anyway, I think you just jinxed it. As soon as someone says something
won't happen because it has never happened in the past, it will happen. :)
--
Joe Seigh
SenderX
I wonder why the Intel hardware architects never thought that somebody might
find it useful to cas a pointer with a word... They give you the ability,
then they take it away!
:O