Author: Matt Taylor
Date: 21:42:23 03/07/03
Go up one level in this thread
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. >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." >><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. >>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. >><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
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.