Computer Chess Club Archives


Search

Terms

Messages

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

Author: Matt Taylor

Date: 16:59:47 03/03/03

Go up one level in this thread


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:
>>>>>
>>>><snip>
>>>>>>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
>>>>>>lead.
>>>>>
>>>>>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
>>chips.
>
>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.

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

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

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

>>http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/20734.pdf
>>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:
>>ftp://download.intel.com/support/processors/procid/24161815.pdf
>>
>>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.

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

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.

-Matt



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

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