Computer Chess Club Archives




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

Author: Robert Hyatt

Date: 11:58:21 03/04/03

Go up one level in this thread

On March 04, 2003 at 13:33:50, Matt Taylor wrote:

>On March 04, 2003 at 11:23:17, Robert Hyatt wrote:
>>On March 03, 2003 at 22:05:39, Jeremiah Penery wrote:
>>>On March 02, 2003 at 23:43:41, Robert Hyatt wrote:
>>>>It was about (for example) Wal-Mart.  They are _not_ copying another operation.
>>>No?  There weren't other large-scale discount retailers before them?  I can name
>>>more than a few.  Even if they didn't copy someone, how does it say they exhibit
>>>'no innovation'?
>>What _technology_ are they copying?  Do they have to look _exactly_ like another
>>store in order to sell?  What _other_ stores have both normal merchandise _and_
>>grocery operations together?
>>As I said, they are _not_ the same.  Wal-Mart doesn't have to have light bulbs
>>on Aisle 1,
>>row 2, near the top, arranged in descending order from high-wattage to low,
>>clear first
>>and frosted last, floods in the middle.
>>AMD _does_ have to follow an absolutely specific set of requirements...
>>So your analogy simply seems _meaningless_ to me...
>>Apples and oranges.
>Sort've. I can write yet another x86 emulator. There are already a dozen around
>(VMware, Virtual PC, Bochs, Plex86, etc.). They all conform to the x86 standard,
>but that doesn't make them the same. Some are faster, Bochs is slower. Hardware
>is no different.
>For that matter, you could try and claim that MIPS and Sparc are really the same
>architecture because their design philosophies are very similar. It's the same
>story with any two x86 chips, even if Intel made both. Each chip is different.
>Each chip is free to innovate, even if they are constrained to support the x86

Yes...  but that is a _mouth-full_.  The ISA is not just instructions like add,
etc.  Don't
forget all the hardware stuff, MSR stuff, VM hardware stuff, exception stuff,
stuff, etc.  X86 compatibility is a _big_ project.  And Intel changes things
from time to
time, for many reasons (probably incompatibility is one of them no doubt.)

>>>>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...
>>>Intel isn't forced to license the instructions (SSE, SSE2, etc.) to AMD.  If
>>>they really thought that supporting some instructions that AMD doesn't support
>>>would be crushing, they wouldn't license the instructions.
>>You need some business experience.  The issue is _timing_.  I can safely deliver
>>a version
>>of Crafty today that has something nobody has seen before.  If it makes it
>>better, I can sell
>>many versions before everybody else figure it out and "catch up".  The "window
>>of opportunity"
>>is what this is about, not monopolistic practices..
>>When Intel announces something "new" they have a window that stretches for
>>however long it
>>takes the opposition to implement the changes.  Or if they choose not to, they
>>can choose to
>>make those "changes" a big deal in advertising which will hurt the competition.
>>So the
>>followers have to follow for the most part.
>Software still has to be updated. HT is a very good example. So are MMX, 3DNow,
>and SSE. The window isn't too important when it requires sweeping changes to be
>implemented. Intel had to wait several years to implement SSE because they had
>to let software catch up. They introduced the FXSR (Fast Float Save & Restore)
>extension which allowed the processor to dictate the size of the floating point
>state. Thus they could introduce SSE and make that state larger.
>>>>For example, automobiles are different.  Because one vendor doesn't set the
>>>>specification _precisely_ and then everyone else has to match _exactly_.
>>>Cars all have to have certain parts - engines, tires, etc.  x86 processors all
>>>have to support certain instructions - ADD, MOV, etc.  That's all.
>>Not by a _long_ shot.  Just pull out the system programmer's book from Intel and
>> the internals of the X86 as it applies to O/S specific issues.  There is a
>>_huge_ volume
>>of stuff that has to be followed exactly.  And it has changed from chip version
>>to chip
>Fortunately, no. The last major change to x86 systems programming was
>implemented in the 386. All other changes (VME, DS, PAE/PSE/PSE36, TSC, GPE,
>etc.) are extensions. By nature they are backward-compatible, and the OS does
>not have to take advantage of them.
>I would not describe the basic 386 model as a "huge volume of stuff" because it
>is moderately simple once you understand how it works. I know someone who wrote
>a 386 emulator in less than a day.

I have written multiple emulators, but not for X86.  I'd bet this was _not_ a
emulator.  IE what about VM?  What about interrupt timing?  A good emulator
handles all correctly.  The VM part of the first emulator I wrote (for the Xerox
Sigma 9)
was very complicated.

But you didn't say how complete the emulator was.  IE only for user
applications?  Mine would
boot an operating system from ground up and look just like a real system.  I did
it so I could
test O/S changes without having to shut down a campus mainframe when testing...

No way that would be a 1 day project.  Not even a one month project.  But it was
faithful to
_everything_ from interrupting timing, to real time clock timing, to whatever,
so that although
everything ran slowly, it ran correctly.

I'd bet doing I/O emulation would be a good week's work to get something that
various types of disk hardware, various formats for CCHHSS, interrupt delays,
programs and the timing of same, etc...

> Implementing all the extensions is a bit of a
>pain, but they are not -required- by the x86 ISA. In fact, I know someone with a
>new Tablet PC that uses a 1 GHz Transmeta Crusoe, and I had him report his CPUID
>feature flags to me. The Crusoe doesn't even support everything the Pentium had,
>but Microsoft still endorses it, and Windows XP runs fine on it.

That's ok.  But it isn't the point.  If you sell me a box that claims to be
"intel compatible"
and it isn't, I am going to get into trouble if I am a naive user.  That is what
happened with
the K6 scenario I described.

>>>The instructions a processor executes don't define the processor.  Otherwise,
>>>there wouldn't be such radically different designs as the P4 and the Crusoe,
>>>among others, both executing the same instructions.
>>As I said, you are looking at the surface.  I'm looking deeper.  Just find the
>>PDF I mentioned at Intel and download it.
>I have the IA-32 Intel Architecture Software Developer's Manual both Volume 2 &
>3 sitting on my desk right now. Volume 2 is the instruction reference, and
>Volume 3 is the System Programming Guide. (I also have them in PDF, but hard
>reference is nicer.) Volume 3 is much thinner than Volume 2.

My volume 2 is about 500 pages.  Last page number is 3-467 with another 50+ in
appendices, plus sections 1 and 2 that are numbered independently.  My vol3 is
1/2" thicker.  The page numbers are different so I am not sure how big, but at
least 600
pages.  "Intel Architecture Software Developer's Manual.  Volume 3:  System

A _lot_ of information.

A _lot_ of precise specifications that a CPU has to meet.

>>>>If there were analogous cases to Intel/AMD, I'd buy it.  But name _one_
>>>>field where one company gets to design the specifications, change them when
>>>>they want, and that must be followed _exactly_ by the competition.  Where
>>>But it's not true that AMD has to follow _exactly_.  When they do, it usually
>>>comes at a leisurely pace.  It's not like they're forced to introduce new
>>>instructions sets within a week of Intel, or lose market share because of it.
>>Right.  Don't you think if they were _exact_ clones, just cheaper, they would be
>Exact vs. non-exact clone has nothing to do with it. The average computer-savvy
>person doesn't know what cmovcc is or which processors have it, so you can't
>expect the computer-illiterate masses to have any idea either.

No, and that is _the_ point.  The average person, when told by a sales person
can buy machine A here for 1799 with monitor and everything, or you can buy
machine B here for 1599.  It is actually a faster processor but is Intel
Then that person is going to assume that software that runs on one will run on
other.  This is not always true, particularly in the "freeware" world, where
exists.  And _there_ is a problem.  One I understand, of course, but not one the
average non-computer person will deal with.

Fair or not, that _has_ had an impact on AMD reputation.

>Dell and Gateway sell Intel because they had to make a choice. I don't know why
>they picked Intel over AMD, but it has nothing to do with cmovcc or instruction
>support and everything to do with money and marketting.

It is the same reason folks buy Maytag appliances rather than "acme".  Name
reputation and trust.  Nothing more.  I'd rather sell Maytag _and_ "acme".  But
if Maytag
tells me "You can sell Maytag, but if you sell 'acme' we are going to stop using
you as a
distributor" then I realize I am going to be worse off with no Maytag and
selling "acme"
than I am if I sell Maytag and no "acme".

>>>>  There are a few "givens" that all manufacturers have
>>>>to deal with.  But only a few.  Processor = X86 or compatible.  Some form of
>>>>off-the-shelf FAM.  One of dozens of disk drives and drive interfaces.  Ditto
>>>>for CD/DVD/etc.
>>>And for x86 processors, the only "givens" are the x86 instructions.  Intel
>>>doesn't get to tell AMD what its processors will look like, or how it executes
>>>those instructions, or how much cache it will use, or anything else.
>>No, but if a program runs on a current X86 and fails on a current AMD, then AMD
>>a problem.  That was my _only_ point.  It happened with the K6 and CMOV for me.
>>didn't compile the program.  I remember the "announcement" that it requires a
>>PII or
>>better.  And it wasn't long before the debugging started.  And the first few
>>reports didn't
>>even mention "AMD" as they thought AMD and Intel were _identical_.  They
>Which is why CPUID was added to the ISA around '93. That issue doesn't come up
>very often. Yours is the only case I have heard of aside from the Win95 timing
>loop bug. If Microsoft bothered to make sure they were compatible with AMD, that
>wouldn't have happened either.

This has come up _many_ times in the freeware/shareware world.  It even came up
in the 386 days when floating point was optional.


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.