Computer Chess Club Archives




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

Author: Robert Hyatt

Date: 17:21:47 03/03/03

Go up one level in this thread

On March 03, 2003 at 19:59:47, Matt Taylor wrote:

>On March 03, 2003 at 17:25:18, Robert Hyatt wrote:
>>On March 03, 2003 at 16:33:07, Matt Taylor wrote:
>>>On March 02, 2003 at 10:28:02, Robert Hyatt wrote:
>>>>On March 02, 2003 at 00:57:18, Matt Taylor wrote:
>>>>>On March 01, 2003 at 20:23:24, Robert Hyatt wrote:
>>>>>>On March 01, 2003 at 11:58:14, Jeremiah Penery wrote:
>>>>>>>It's the reason Intel was able to sell their processors at higher prices than
>>>>>>>AMD, and sell several times more of them, even when AMD had a clear performance
>>>>>>Maybe.  Maybe Intel was also known for some good things.  IE the fact that the
>>>>>>current PIV will _still_ execute the original 8086 machine instructions.  Ask
>>>>>>sun what a mistake it is to break that consumer confidence and say "OK, for our
>>>>>>next generation processor, you get to throw away all your old software and buy
>>>>>>all new software..."  And they went from the largest academic workstation
>>>>>>supplier to a has-been overnight.
>>>>>In the context of Intel vs. AMD, that's a moot point. AMD documents things that
>>>>>Intel denies even exist (salc, icebp, loadall, etc.). AMD processors not only
>>>>>support the full ISA, but they support undocumented instructions. (Most of these
>>>>>undoc'd opcodes were related to old ICEs.)
>>>>>>I consider Intel a "name brand".  I consider AMD a "copier".  Nothing wrong with
>>>>>>being a "copier" but it also means you are a "follower".  And 2nd place is all
>>>>>>that a follower can _ever_ reach...  I have nothing against AMD whatsoever.  But
>>>>>>I have had good results with Intel since my first 4004 on a breadboard, and I
>>>>>>have stuck with what works ever since.  By the same token I have owned multiple
>>>>>>Mercury outboards, even though there are cheaper ones from places like Japan.
>>>>>>But my mercs have been rock solid, produced more horsepower, and weighed less,
>>>>>>and those are important qualities and I don't leave a winning combination to
>>>>>>try something else someone is doing to try to catch up with Merc.
>>>>>Intel outsells for 3 simple reasons:
>>>>>(1) Consumer ignorance
>>>>>(2) Brand loyalty
>>>>>(3) Strongarm tactics
>>>>>Consumer ignorance is what happens when my coworker tells me that he thinks AMD
>>>>>doesn't correctly support all x86 instructions. I proceed to laugh, and I ask
>>>>>him how he could possibly think that.
>>>>That was not urban legend.  It happened.  You can find threads here a few
>>>>years back where folks were complaining about Crafty crashing on AMD processors.
>>>>We found that things like CMOV were missing at the time, yet AMD was claiming
>>>>compatibility.  Not a huge problem, but it _was_ a problem that caused me a
>>>>_lot_ of email and testing to discover what it was.  There have been a few other
>>>>such cases, CMOV wasn't the only thing.  3DNow was another thing that seems
>>>>pretty pointless, since Intel dominates sales, who is going to take the risk of
>>>>using non-Intel stuff?  Not many software developers will, and we end up with
>>>>_another_ incompatibility.
>>>Then that is a bug because the feature flags in CPUID function 1 report which
>>>extensions the processor supports. One of these is the cmovcc instruction. The
>>>original Pentium did not support cmovcc, so you are required to check the flags
>>>if you want your code to work on a Pentium. The same goes for the K6 line of
>>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."

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.  :)  )

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...

>>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.

>>I think the confusion point was that The person compiling for me (not Eugene
>>at the time) assumed that when this problem arose, it was something else, as
>>it would run on current pentium processors (PII) but it failed on current (at
>>the time) AMD processors.
>>Whether it was a user error, for trying to run code for a too-new processor,
>>or whatever, it simply caused some interesting support issues.  I didn't do any
>>CPUID tests in anything I did, for example, and didn't want to waste the time
>>with code produced for either.
>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.

>>>I don't know offhand what the original K6 reports for feature flags, but my K6-2
>>>here reports 0x008021BF. Bit 15 (0x00008000) is support for cmovcc, and I don't
>>>see it set. I have a document from AMD entitled, "AMD Processor Recognition
>>>Note" (20734). AMD lists values that each processor returns for each supported
>>>CPUID function. None of the entries for any of the K6-series processors has bit
>>>15 set in the feature flags.
>>I think that was the confusing point, since they were generally advertised as
>>"Intel compatible".  But they weren't...  at least not _completely_ compatible
>>at the binary level.  Yes you could discover they were not with CPUID, but
>>that was another story...
>You can be compatible with the 386 and technically be "Intel compatible." I
>don't recall AMD ever specifically saying the K6 supported everything the
>Pentium 2 supported. The Pentium and some 486 variants supported cpuid as a
>mechanism for detecting features. Alternatively you can simply say, "I require a
>Pentium 2 or better," and rely on the user to put 2 & 2 together. Since Crafty
>is open source, you can always suggest the user try recompiling for their

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.

>>>Look at the EDX register under CPUID standard function 1. You can verify the bit
>>>position for cmovcc on page 34.
>>>Here is Intel's document:
>>>There was also a compatibility bug in Windows 95 that was blamed on AMD. This
>>>was hardly AMD's fault. There was a timing loop that relied on the loop
>>>instruction being slow. The K6's loop instruction took 1 cycle. As clock speed
>>>increased, the timing loop became fast enough that it failed. This is
>>>Microsoft's fault, not AMD's fault.
>>Wouldn't disagree, although from an engineering point of view, "compatible"
>>means "similar to".  Branch loops are not uncommon for timing at certain points,
>>and if a processor runs 'em too quickly, that's certainly a compatibility
>>problem, exacerbated by a poor software design...
>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.

>By your definition, "compatible" is extremely subjective. I consider the K6
>"compatible" with the Pentium because it executes the same instruction set --
>definitely a major similarity. If you go as far as to include instruction
>timings, the 486 must not be "compatible" with the Pentium nor any other IA-32

Note that it isn't "my definition."   I understand the differences.  I am
talking about
"John/Jane Doe" and the definition they expect.  IE if an appliance says "110v"
they expect to plug it in at home and see it work.  Perhaps they didn't notice
that it
said "30 amps" and that requires a different receptacle.  All they know is that
wouldn't work at home and they want something that will to replace it.

>This issue was entirely a Microsoft bug. Their failure to write good code or
>support non-Intel products is not AMD's fault. Many older timing loops had
>failed as processors got faster. People knew better. Microsoft did it anyway.

I wouldn't disagree in that limited case.  Timing loops are _never_ the way to
do this.  Have you ever heard me write about "the auto232 stuff which is a piece
of trash?"  If not, I use "piece of trash" because it has the _same_ kinds of
problems that the end-programmer has to deal with.  Without knowing how to
set the timing delays since it varies for each processor.  Complete nonsense.

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.