Computer Chess Club Archives




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

Author: Robert Hyatt

Date: 14:10:55 03/03/03

Go up one level in this thread

On March 03, 2003 at 16:44:12, Matt Taylor wrote:

>On March 03, 2003 at 09:50:12, Robert Hyatt wrote:
>>On March 03, 2003 at 02:09:52, Matt Taylor wrote:
>>>On March 02, 2003 at 23:43:41, Robert Hyatt wrote:
>>>>Intel _defines_ the X86 architecture, because they _are_ the X86
>>>>architects.  Anybody making compatibles (AMD) is _following_.  Which means
>>>>they will always be "behind".  Because Intel will change the specs, and start
>>>>shipping chips, and AMD has to quickly catch up.  That's just the way it is
>>>>when you are copying your competition's product exactly...
>>>Oh, oh, but this isn't completely true anymore. In the days of the Pentium, AMD
>>>and Intel weren't the only two x86 chipmakers. There was also Cyrix, IDT,
>>>Evergreen, and a few others. I do not recall many details, but 3DNow was part of
>>>a bigger open extension to x86 backed by everyone except Intel, and Intel agreed
>>>to remain compatible even if they wouldn't support it. Essentially it meant any
>>>vendor could propose and implement an extension to the x86 ISA. The extension
>>>opcodes were put in the 0F 0F opcode map. 3DNow was the first and AFAIK the only
>>>extension proposed in this consortium.
>>>All those other vendors are no longer on the x86 playing field, but Intel still
>>>"respects" in a manner that agreement. They will never support 3DNow, but they
>>>will never break it either.
>>>Also, there is the x86-64. I suppose you could consider it a seperate ISA, but I
>>>don't see it as being any different from what was already happening to x86.
>>>Furthermore Sparc, MIPS, and others have done the same thing -- complete
>>>backward compatibility in their ISA. Ironically Intel was building an x86-64
>>>chip. I've heard since that they've canned the project. You can't blame them;
>>>isn't it rather embarassing when you're following someone else regarding your
>>>own architecture?
>>X86-64 has the _same_ problem.  It has to remain "true" to the Intel X86
>>architecture or
>>it won't sell at all.  When Intel adds new instructions (CMOV is one example)
>>then any
>>new copycat chip _must_ support it or it will be broken and have no market.
>AMD didn't support SSE for a long time. That didn't slow AMD sales at all. AMD
>still doesn't support SSE 2, although the K8 will support it. AMD's sales are
>slow for other reasons.

I don't think SSE2 was as big an impact as CMOV.  That was an instruction,
taken from the alpha architecture, that had a potential for serious impact
on performance since it eliminated branches.  The critical issue is "does the
current compilers emit the new instruction naturally?"  If the answer is yes,
then it has to be supported or else.  I've been getting cmovs from GCC for
quite a while, although according to reports here VC doesn't produce them which
almost makes them a moot point.

>Regardless of x86, the x86-64 is still AMD's architecture. They are no longer
>following as they have defined the new rules. The x86-64 is an open architecture
>just like Sparc.
>>The point being not that AMD is bad, but that they have chosen to cast their lot
>>intel in an attempt to usurp part of their market share, which is a perfectly
>>valid decision.  But
>>it means they will _always_ be following Intel because they have to maintain
>>compatibility with the core architecture.
>The "core architecture" has not changed in over 10 years. Addition of cmov, SSE,
>or whatever else you care to bring up uses a well-defined Intel mechanism that
>allows for backward-compatibility. The only change to the core architecture is
>that x86-64 is now 64-bits, not 32-bits, and AMD has changed the instruction set
>a good deal. Being backward-compatible does not mean they're following Intel.
>The x86-64 really isn't following anything.

The problem however, is that they _must_ keep X86 compatibility.  And things
like cmov are just part of the issue.  Think of all the O/S specific stuff with
MTRR, memory management, 36gb address space, etc...  makes life interesting as
there details are important and there are _lots_ of details in the bare X86

>>As far as 3dnow, it seems pretty "3d dead".  Microsoft will have more to say
>>about that since
>>they have the dominant compiler project for X86, and if they aren't going to
>>produce the
>>code natively, nobody is going to care except for a few of us that twiddle with
>>asm() stuff
>>on our own...
>Microsoft has never supported MMX, 3DNow, or SSE in their compiler. That doesn't
>make any of them dead. I consider 3DNow dead because Athlon also supports SSE,
>but some people -still- use 3DNow. Many games support 3DNow as well as SSE, and
>I think games and desktop multimedia were really the primary target of vector
>extensions anyway. I don't know whether professional rendering programs like
>Lightwave support any vector extensions, though I would imagine they do.

I think a few CAD companies tried to support _both_.  I'm not sure how it
turned out although from a software engineering perspective, it would be ugly.

My only point here is that given a choice, I would rather be doing the leading
edge changes to an architecture, rather than following along trying to remain
compatible, because the follower always has a catch-up curve to deal with when
the base platform changes.

I certainly understand why they chose to do this, because Intel had a _huge_
market share and they wanted a piece of the action, as Cyrix did back in the
old days of separate floating point co-processor chips and the like...

This page took 0.01 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.