Author: Robert Hyatt
Date: 22:37:18 03/07/03
Go up one level in this thread
On March 08, 2003 at 00:42:23, Matt Taylor wrote: >On March 07, 2003 at 23:37:24, Robert Hyatt wrote: > >>On March 07, 2003 at 17:42:42, Matt Taylor wrote: >> >>>On March 06, 2003 at 11:40:16, Robert Hyatt wrote: >>> >>>>On March 06, 2003 at 08:14:00, Andrew Dados wrote: >>>> >>><snip> >>>>>Now.. when you or whoever made crafty binary didn't read specs and released >>>>>buggy software (assuming it can be compiled for PII and run on k6), you try to >>>>>blame AMD for that. >>>> >>>>I'm not blaming AMD for me not reading the specs. If you don't follow the >>>>problem >>>>there is little I can do to convince you there is a problem. But suppose a >>>>brand new programmer >>>>compiles something and sends it to his buddy where it promptly crashes. Is it >>>>_his_ fault that >>>>he didn't realize Intel PII had instructions the AMD K6 (PII compatible) didn't >>>>have? >>> >>>Yes. >>> >>>Usually companies will state that it works under a specific set of conditions. >>>Some people will try to run it on other hardware, and it will sometimes work. >>>Other times it fails. When they ask for tech support, the tech tells them that >>>the company does not warranty that the product operates on his hardware. >>> >>>>You buy a car in 1966. You put it in a garage for 10 years while you are out of >>>>the >>>>country. You come back, and after driving it 5000 miles the engine falls apart. >>>> Upon >>>>inspection, the valve seats have worn and the valves broke, destroying the >>>>engine. Should >>>>_you_ have known that in the 10 years you were away, we switched to unleaded >>>>fuel and >>>>your engine depended on the lead for valve seat lubrication? >>> >>>I can't speak for 1966 since I was not alive at that point in time. However, my >>>car came with a manual that specifies that my car runs best with 87 octane fuel. >>>As a result, I buy 87 octane gas when I put fuel in my car. >>> >>>In the AMD/Intel analogy, the manual is around. It is not as obvious, but >>>ignorance does not make it AMD's fault. >> >>No... but it causes problems. IE suppose _today_ someone sells a car that >>requires leaded gas? Who would expect that since everybody else uses >>unleaded? Does an 80-year old Grandmother have to read all the owner's >>manual and warranty booklet to find the fine print "leaded fuel only?" > >And 30 years in the automobile industry is somehow equivalent to a couple years >in the chip industry? While systems become outdated in a mere 3 months, >architectures and implementations themselves last much longer. You don't have to go to that extreme. Unleaded became a requirement around 1972 if memory serves me. Jump a couple of years past that into the future and you have the _same_ scenario. > >>That's the point. Yes, I suppose you could make a case that anybody should >>read the docs before they use the product. But in reality, you know that >>nobody does, because the assumption is that all vehicles use currently available >>unleaded fuel unless great big warning signs are everywhere... > >Your analogy is flawed at the core. A better analogy would be condemning >Plymouth for releasing an automobile with a big sign on the side that says, >"Leaded fuel," when it breaks after the owner puts in unleaded gasoline. The K6 >has a big stamp on it called CPUID that says, "I can't do cmovcc." It doesn't have a "big stamp" which is the problem. It has a Big Stamp that says "X86 compatible". And back on page 400 you discover "but the cmovxx instructions are not implemented in this processor." What is a "big stamp" to you is a fine-print disclaimer buried on page 400 to a "grandmother program developer." :) > >>><snip> >>>>That is where we were with the PII/K6 problem. _technically_ it was a user >>>>problem. But >>>>what about "practically"? Does a little old lady that is 70 years old have to >>>>investigate such >>>>details about her new vehicle, when she couldn't tell the difference between a >>>>spark plug and >>>>a spare tire? >>> >>>Technically it was a developer problem because users aren't expected to know the >>>difference between a K6, Winchip, 5x86, or any of the other billion competing >>>chips. The CPUID instruction was not originally added for this purpose, but it >>>was not long before this became a very integral role of the instruction. >> >>Unfortunately, there are "80 year old grandmother developers." >> >>:) >> >>I've had more than one person send me a neat new program to test, not knowing >>that SPARC stuff won't run on my X86 box, as an example. If they don't know >>that, they _certainly_ won't know that within a processor "family" there are >>incompatibilities. >> >>>>>I'd think that someone with that much experience would admit to error instead of >>>>>adding to ignorant hype that AMD processors are buggy etc. >>>> >>>>First, it was not obvious. I didn't compile the code. I wrote the code and >>>>someone else >>>>compiled it. And it was running fine all over the world. A few had problems >>>>trying to >>>>run it on 486 and 586 systems but we told them quickly "this requires a >>>>pentium-II >>>>processor. Otherwise download the non-PII version that was also there. But >>>>when it >>>>came to the K6, which _was_ advertised as PII-compatible, nobody considered that >>>>there >>>>might be missing instructions. >>> >>>You keep claiming that it was advertised as Pentium 2 compatible, but I never >>>saw these ads. >> >>I saw them sitting side-by-side in comp USA. With signs saying "Built with >>an AMD inside." And magazine adds hanging in front of them showing the infamous >>"faster but cheaper". If they are put side by side, and even AMD compared >>price and performance, it is certainly _reasonable_ to consider them to be >>compatible. After all, nobody compares a gas automobile to a diesel auto >>without _explicitly_ pointing out the pros/cons of the non-standard fuel. > >Dell sells Pentium 3 systems side-by-side with Pentium 4 systems. Notice anything different? Pentium 3. Pentium 4. They _clearly_ identify what is "inside" is a pentium-X. That's a bit different than just selling something that is compared to the pentium II in your own ads, but which is not quite a pentium-II in fact... > >>>I don't know why nobody thought to try the Pentium version on their K6 or why >>>nobody compiled Crafty for the K6, but I still don't see why this is AMD's >>>fault. The manuals were around, and even Intel said CPUID was necessary. I >>>suppose you could blame the GNU people since their compiler did not produce the >>>prolog code to check for the cmovcc extension. (Actually blaming them would be >>>useful since they might fix that.) >> >>I'm not sure it is "AMD's fault". And I didn't really say that. I said "this >>hurt AMD's reputation in the Intel market" because it happened many times, not >>just with Crafty. It was a topic in many software (and compiler) newsgroups >>at the time. > >Happened in your world, I suppose, but it has never happened in mine. On Windows >I have -never- seen an implementation support issue. Nearly every program I have >toyed with on my Linux machines has come source-only, so I compile for whichever >machine I'm running it on. I've _always_ found executable-only programs for linux, for windows, for dos, for you-name-it. And there, you are at the mercy of the person that compiled the code. Early example: a c shell for dos. To replace command.com, with a unix-like command-line interface. Executable only. A unix library of commands like ls, tail, head, etc. Same deal. For windows, I've downloaded _many_ programs that were .exe only. A program to compute prob slippage for a boat. (a simple program) to large applications that the author wants to protect the source for. For linux, there are dozens of chess engines alone (windows too) that are only distributed in executable form. Not to mention all the other applications that are available without source. 99% of crafty users don't have any idea how to compile the thing... > >>><snip> >>>>Nothing wrong with your liking AMD. This was about a problem they _did_ have >>>>and >>>>it was not isolated to just Crafty. It happened with _many_ freeware-type >>>>programs and >>>>everyone learned that pentiumII was not a good target architecture for compilers >>>>due to >>>>the AMD incompatibility with cmov. >>> >>>Not incompatibility. The spec allows a processor to not implement cmov if it >>>reports it, and the K6 does. Perhaps the GNU compiler is incompatible. They >>>should add an x86 functionality check function to the library and call it from >>>the main function to ensure that all necessary features are implemented. >>> >>>-Matt >> >>Again, technically you are correct. But practically, ... > >Practically it is still hard to say. Perhaps I think radically different, but I >would blame the software. > >-Matt Wouldn't it be an ugly world if compilers were done the same way. "We implemented everything but this, because this was too hard. but you can test to see that this wasn't implemented..." Note that "this" is a compiler intrinsic like long or double, not a library function that really isn't part of the C standard. Or a program that implements "most" of the winboard protocol, but not all, and which blows up when it gets a command it doesn't support. But the command isn't used much so it doesn't hurt all the time... For example the commands needed to resume an adjourned game. If I try to implement something for which there is a precise specification, or a precise protocol, I try to at least _handle_ all features even if I don't think I will ever use them, so that I don't choke and puke on something unexpected.
This page took 0.01 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.