Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Introducing "No-Moore's Law"

Author: Matt Taylor

Date: 14:42:42 03/07/03

Go up one level in this thread


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.

<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.

>>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 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.)

<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



This page took 0.02 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.