Author: Robert Hyatt
Date: 21:39:55 03/03/03
Go up one level in this thread
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: >>> ><snip> >>>>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? > >>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 >>can >>argue about whose fault it is, whether the salesperson should have said "it is >>almost >>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 >>be >>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). >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. 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 that?" I think that is gross. _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, 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 >>time, >>with AMD claiming compatibility, that the two _really_ were compatible. not >>that >>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". > >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 >>time >>as the P6/PII. And advertised as "compatible but more bang for the buck." And >>it >>did cause some confusion. ><snip> > >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. > >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. > >>>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 just tell everyone "it _must_ have a pentium pro or PII or beyond." I had >>the >>same problem in the 486 days where I had one floating point operation in the >>whole >>program to compute NPS, and on a 486SX... crash. ><snip> > >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 >instructions. 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... > >>Again, to the _layperson_ AMD markets themselves as "intel replacement >>processors >>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. ><snip> > >I don't think most of what I call consumer ignorance stems from this, though. My >coworker decided that NT BSODs were AMD's fault because he didn't seem to get >them on his Intel machines. The real reason was because he didn't play games on >his Intel machines. 3D graphics drivers are notoriously buggy. He tried to blame >AMD with mythical incompatibility, but it's not even related to AMD. I told him >that many times and explained to him how he could fix the problem, but he was >content to blame AMD. > >After the death of Macintosh, AMD vs. Intel seems to have become the predominant >debate. I have talked with many nontechnical (lay) people who believe that AMD >is trash. I don't think any of them ever used an AMD machine, though. It is easy >to think that AMD is inferior because Intel is the brand name. I was always >unconvinced until I replaced my Pentium 120 with a K6-266. > >>>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. ><snip> > >Only if they managed to upgrade existing systems in-place. They have >infrastructure to do that now and they -still- can't make it work because people >disable the automatic updates. They may fix it in Win98, but someone with Win95 >would inevitably install it on a faster Pentium 3, and it would fail to boot. > >-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.