Computer Chess Club Archives




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

Author: Matt Taylor

Date: 10:38:53 03/04/03

Go up one level in this thread

On March 04, 2003 at 00:39:55, Robert Hyatt wrote:

>On March 04, 2003 at 00:09:19, Matt Taylor wrote:
>>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.
>So, back to my earlier example, you think that "Mrs John Doe" should _know_
>that when she sees 110v 30a that such an appliance won't plug in and run in
>her house?  Even though it is replacing one that does plug in and run?  She
>is supposed to verify what the salesman says?
>I think the company has some responsibility in its advertising to be specific
>about what an appliance (or a microprocessor) will and won't do.  "equivalent
>to Intel" has a meaning to the lay-public.  And it _isn't_ "almost the same,
>although some programs might not run."
>>I guess I should add a 4th reason to that list. The 4th reason would be buggy,
>>incompatible software.
>Software _can't_ be incompatible, when a chip vendor says "buy mine, it is
>compatible with theirs and it is cheaper and faster."  The buyer has to
>determine whether it is or not?

The spec still says that you have to check via cpuid. I consider software that
does not follow the spec to be buggy. It is the same reason why you can't always
take a POSIX program and run it on another POSIX platform. There are bugs in the
libraries sometimes. If they all followed spec, there would be no porting
issues. Same thing for the ISA.

>>>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.
>And branches everywhere you need to decide which block of code to
>use (CMOV or CMP/JE/JNE).

Nope. The easiest way is to check for cmov in the init code. If you have no
cmov, then:
    printf("Your system is not supported.);

Alternatively you can trap the illegal instruction exception and emulate it
(horribly slow on processors that don't support cmovcc). Or you can self-modify
(cache line flush paid for each cmovcc). Or you can use a bloated exe and use
function pointers to dynamically select which routines you use (penalty paid
every time a new branch is encountered). Or you can dynamically relink yourself
(penalty paid on startup, no runtime penalty).

There are a thousand ways to handle this, some easier than others, but all are
better than crossing your fingers and hoping the end user has cmovcc support.
They're also better than trying to figure out why the program broke for one
person and not another.

>>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
>No, but the PII did.  And AMD _claimed_ that the K6 was (a) compatible;
>(b) faster and (c) cheaper.  (b) and (c) are meaningless if (a) is false.

But compatible means nothing...

>Is it good practice to do that?  IE by PII buddy compiles a program and I say
>"hey, I just bought me a shiney new AMD that is faster than your PII, so let
>me try that...  wwwhhhaaattttt???  It crashes every time?  What would cause
>I think that is gross.

Software that uses CPUID vector 1 to check feature flags doesn't crash like
this. I used a K6 for a couple years, and I've never seen a program crash that
wasn't reputably buggy.

>_many_ people don't even know they are running AMD.  Again, the old crafty list
>would have shown this clearly.  It was a pretty common issue back when PII and
>K6 were competing.  And it got to the point that for every crash, the first
>response from anybody on the list would be "AMD?  or Intel?"
>That highlights the problem.
>I spent a lot of time setting up positions, testing, and communicating with
>the users reporting problems.  Until we finally stumbled onto the AMD issue.

But it is a non-issue. How can you ignore Intel specifically saying you need to
check the feature flags? Intel has set the spec up so they can remove newer
parts of the ISA if they want. If you rely on the assumption that they never
remove features, your program will break.

>>>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.
>_Every_ PII would run any pre-PII program.  _every_ PIII would run any PII or
>earlier program.  We said "PII required".  And at that time, AMD was claiming
>superiority in terms of speed and price.  But it _wasn't_ "fully compatible".

Again, the spec says you must check CPUID vector 1 for feature flags. The K6 was
perfectly compatible because it reports that it doesn't have cmovcc.
"Compatibility" does not mean "supports the same things," it means "correctly
follows the specification." I've never heard AMD say, "Our K6 can do everything
the Pentium 2 can do!" They simply claimed Intel compatibility, and they were
right. Crafty is the only instance I have heard of where ISA implementation
differences broke a program.

The branch mispredict penalty on a K6 was something like 3 cycles. That's
probably why they didn't bother implementing cmovcc.

>>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.
>In this case it _might_ have been better.  But the advertisements which put
>it head to head with the PII were not exactly kosher.

What advertisements are you talking about?

>>Technically AMD didn't make any such claims about the K6 because they haven't
>>been allowed to advertise.
>I don't know what that means. They won't sell without marketing.

Ask Vincent. They aired commericials in Europe. They're not allowed to do that
in the U.S.

>>>>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
>What would I say?  I have no idea what failed, in a C program.  Bogus floating
>point (486)?  no cmov (vanilla pentium and AMD prior to K7)?  Etc...

Since it's a C program and the fault lies in the machine, you can always have
the user recompile Crafty for their machine. That is the beauty of open-source.

Still, this is one of extremely few cases where implementation differences
burned AMD. The biggest difference between AMD and Intel lies in their vector
instructions, and I've never heard of an SSE program failing on a pre-Palomino
AMD chip. I've never heard of an SSE 2 program failing on any AMD chip. They
always behave well -- that is, they check the CPUID feature flags and bail
(rather than crashing) when the instructions aren't supported.


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.