Computer Chess Club Archives




Subject: Re: Introducing "No-Moore's Law"

Author: Matt Taylor

Date: 21:09:19 03/03/03

Go up one level in this thread

On March 03, 2003 at 20:21:47, Robert Hyatt wrote:

>On March 03, 2003 at 19:59:47, Matt Taylor wrote:
>>On March 03, 2003 at 17:25:18, Robert Hyatt wrote:
>>>Wait.  The problem happened _after_ the pentium was "gone".  IE after P6 and
>>>PII were out.  I was compiling for the pentium pro and beyond, and at the time
>>>AMD was still selling whatever processor they produced that didn't have CMOV.
>>Why does that matter? From the beginning the spec said "check for cmovcc using
>>cpuid." If you didn't, that's your fault, not AMD's fault. AMD processors
>>followed the spec.
>What do you do for software that is running on your friend's PII, but when you
>load it on your AMD it crashes?  You are simply a naive user and don't know
>anything about architecture.  You just know that when you went down to comp-USA,
>they told you "this machine will do anything the intel-based machine will do,
>for a
>few hundred bucks less."

I would probably blame the software for being buggy. Then again, I'm not
terribly naive.

I don't see how this changes things, anyway. You're talking about perception of
who is to blame. That doesn't change the fact that the software is buggy because
it does not conform to spec. Every time someone assumes something that isn't
guaranteed, their software always fails. That doesn't mean the new environment
is to blame; it means the software is buggy.

I guess I should add a 4th reason to that list. The 4th reason would be buggy,
incompatible software.

>It won't, always.  I didn't fail to test the CPUID capability flags, and the
>compiler wasn't
>told to do so for speed reasons.  And there starts a long, complex, worrisome
>path to
>aggravation.  Because the "compatible processor" wasn't "really compatible".  We
>argue about whose fault it is, whether the salesperson should have said "it is
>the same but it is missing some new instructions that might cause you problems
>if an
>application is compiled specifically for the pentiumII."  Or whether the
>compiler should
>test for CMOV capability, which I would strongly object to when I want to target
>a specific
>machine for max performance.  Or whether we should blame Microsoft (they seem to
>a good company to blame for anything.  :)  )

The CPUID test can be done during initialization. For a flexible system, you can
use function pointers and do it at runtime. This has obvious disadvantages. You
can also patch the program at runtime. There are a billion options, but the
fallback method is to bail up-front if you don't have support for cmovcc. That's
easy, and it costs only a few nanoseconds during initialization.

The fault still lies in the software because CPUID vector 1 feature flag
detection is the -standard- way to do it, and it has been well publicized in
Intel literature. The Pentium does not support cmovcc

>But, in reality, there was an unhappy user.  And a lot of testing back and forth
>with emails
>to the crafty list, before we figured out what was happening.
>Now I know to ask that question (Intel or AMD) but I didn't at the time, not
>being an
>AMD user.  I assumed that if Intel and AMD were producing chips at the same
>with AMD claiming compatibility, that the two _really_ were compatible.  not
>one had missing instructions that I could detect if I wanted to...

Compatibility with the spec, yes. Part-for-part compatibility, no. No Intel chip
has been part-for-part compatible with any other Intel chip.

The spec -still- says you don't have to support cmovcc, MMX, SSE, etc. In fact,
the VIA C3 processor doesn't support most of it. (I can't remember what they do
support, but it's very minimalist.) The VIA C3 is perfectly compliant because it
properly reports this through CPUID vector 1.

Any software that assumes the processor has cmovcc should either publish that
fact, or it should check the processor with cpuid. (Users are stupid so it
should probably check anyway.)

>>>I didn't tell the compiler "produce code that will run on any machine" I told
>>>it "produce code for the P6 instructions (or PII, I don't recall now)"  And
>>>new AMD machines were having problems.  I certainly don't remember now whether
>>>it was only K5 or early K6, that was too far back.  I just remember the problem,
>>>although we also saw it a _few_ times with people using old original pentium
>>>processors of course...
>>If you require P6 instruction support, it won't work on the K6. You wouldn't
>>expect a Pentium to work with P6 instructions, would you? The K6 is stuck
>>somewhere in between.
>I understand.  But the problem is that the K7 was selling at _exactly_ the same
>as the P6/PII.  And advertised as "compatible but more bang for the buck."  And
>did cause some confusion.

The K6 is compatible by the docs. A lot of software is broken, but there is only
so much you can do about that. It is unfortunate that AMD is penalized for
making a better product.

Technically AMD didn't make any such claims about the K6 because they haven't
been allowed to advertise.

>>I wouldn't either. It's annoying to support. However, it is part of the
>>architecture. Perhaps this is why VC does not generate instructions for newer
>>You encounter the same issues when dealing with people that use the original
>>Pentium, 486, etc. This is why you're supposed to use cpuid to detect the
>>feature set at runtime to double check. You can at least bail if it doesn't have
>>a required feature. It's a bit harder when dealing with GCC because you might
>>not think of some feature the compiler uses, but AMD can't really be blamed for
>I just tell everyone "it _must_ have a pentium pro  or PII or beyond."  I had
>same problem in the 486 days where I had one floating point operation in the
>program to compute NPS, and on a 486SX...  crash.

Not all 486's had cpuid, but you can still trap the exception (Unix signal). For
that matter, the cpuid instruction can also be avoided by trapping illegal

>Again, to the _layperson_ AMD markets themselves as "intel replacement
>that are cheaper/faster."  Which is almost always true in the case of cheaper,
>and often
>true in the case of faster.  But splitting hairs with end-users leads to the
>many legends
>that abound about AMD problems.  It was only a problem in that the
>"compatibility" was
>not carefully explained.  Yes, I buy the CPUID test idea.  But Joe Blow won't.
>He just
>sees a crash and burn with no explanation about why it works on his friends more
>expensive box but not on his.  I'd bet that has harmed AMD more than they would
>guess, even if it is unfair in a way.

I don't think most of what I call consumer ignorance stems from this, though. My
coworker decided that NT BSODs were AMD's fault because he didn't seem to get
them on his Intel machines. The real reason was because he didn't play games on
his Intel machines. 3D graphics drivers are notoriously buggy. He tried to blame
AMD with mythical incompatibility, but it's not even related to AMD. I told him
that many times and explained to him how he could fix the problem, but he was
content to blame AMD.

After the death of Macintosh, AMD vs. Intel seems to have become the predominant
debate. I have talked with many nontechnical (lay) people who believe that AMD
is trash. I don't think any of them ever used an AMD machine, though. It is easy
to think that AMD is inferior because Intel is the brand name. I was always
unconvinced until I replaced my Pentium 120 with a K6-266.

>>The problem would have inevitably been triggered on Intel processors.
>Maybe.  Or maybe it would have been caught since MS gets prototypes before they
>ship anyway.  And they would probably have debugged the problem and fixed it
>with none of us being any the wiser that they used such a trick.

Only if they managed to upgrade existing systems in-place. They have
infrastructure to do that now and they -still- can't make it work because people
disable the automatic updates. They may fix it in Win98, but someone with Win95
would inevitably install it on a faster Pentium 3, and it would fail to boot.


This page took 0.01 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.