Author: Robert Hyatt
Date: 14:25:18 03/03/03
Go up one level in this thread
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. 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... 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 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... > >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... > >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.