Author: Matt Taylor
Date: 13:33:07 03/03/03
Go up one level in this thread
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. 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. 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. At the time 3DNow was released, it was very useful. It was backward-compatible just like MMX was, and it allowed SIMD FP operations whereas MMX didn't. SSE was not available at that time. A fair number of programs were patched to use 3DNow on AMD processors. Since AthlonXP supports SSE as well as 3DNow, most new code uses SSE. >>Dell and Gateway are examples of strongarm tactics. Do they sell AMD? Not >>anymore... > >That happens everywhere. Eg "windows" from Microsoft... > >As I said, I'm not anti-AMD. I'm simply an Intel fan from past product >experience. I'm also an alpha fan. And a Cray fan. And in each of those >cases, those vendors were the _leaders_. It really wouldn't matter even if you were anti-AMD. The point is that many other people seem to be anti-AMD. Dell transitioned to exclusively sell Intel when AMD maintained a definitive performance advantage over Intel's Pentium 4, and the Pentium 3 was unable to offer compeition at that point in time. Shortly thereafter Gateway made the same choice. The leader in desktop performance changes whenever new chips come out. Workstations have always been dominated by Intel because there was no competition until recently. However, this is about desktops, not workstations. -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.