Computer Chess Club Archives




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

Author: Robert Hyatt

Date: 20:06:39 03/04/03

Go up one level in this thread

On March 04, 2003 at 19:22:50, Matt Taylor wrote:

>On March 04, 2003 at 14:58:21, Robert Hyatt wrote:
>>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.)
>Nonsense. 486 is all you have to support to be compliant with the full ISA.

You remind me of my son.  :)

To wit:  when the "walk" light comes on, he is going to walk across the
street because he _has_ the right of way.  I keep telling him that he is
right of course, and one day he might end up _dead_ right.

I personally look before walking regardless of the color of the light.  I look
before I leave when a light turns green, to be sure some idiot is not going to
run the light and make _me_ "dead right".

And that is where we are here.  You want to advertise that a machine is
equivalentto intel, but faster and cheaper, feel free.  And if you want to stand
on the fine print "but if a program uses cmov without checking the CPUID
processor capability bits it is a bad piece of software."  But the _customers_
will think the machine is broken, and _they_ are the ones you are trying to
market to.  You end up right.  Dead right.

There is "right" and there is "right".

>Like I said, I know someone who wrote an x86 emulator in less than a day. Aside
>from some decode bug in his 32-bit support, he was able to boot Win9x.

I'm not going to argue that point.  I've written more than one and I _really_
don't believe it can be done in a day, if you implement the full ISA.  The
memory mapping, etc. cache simulation, with flushing, etc.  TLB.  etc.  If your
friend did it, he's good.  I'd suspect that would be 100K+ lines of a good
high-level programming language if it is a full emulation.

>Intel has -never- changed anything. They have extended, and they have added
>features, but they have never removed support for anything. The few instances
>where behavior does change are errata. The only other changes involve Intel
>defining a function for formerly reserved bits in system data structures.

OK.  I simply suggested that they _could_ if they wanted.  I don't believe in
dark motives of the engineers.  Nor do I believe in the marketing nonsense of
selling chips way below what they could really run at...

>You are welcome to provide an example to the contrary, but I don't know of any.
>>>>>>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.
>Emulate what timings? There are no defined timings in the ISA. Relying on
>timings is a bug.

When you start a disk drive, how long until the interrupt comes in in your
emulator?  That _has_ to be timing based so that approximately the right
number of clock cycles pass before you simulate the interrupt, stop the
current instruction stream and go to the interupt handler address...

>Of course it wasn't a full emulator. All he emulated was basic VGA support and
>keyboard. I don't think he even had a mouse. It was enough to run Windows 3.11,
>and it ran Windows 95 after he fixed the bug.

But I assume he did all the VM hardware?

>>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.
>PCs don't have established timings. I/O is about the only thing that does, and
>the timings are only approximate, on the order of microseconds. Many devices
>(like the keyboard controller) require you to poll their status.

That is fine.  But the real time clock generates an interrupt every N units
of time.  An I/O device takes some N+/-delta units of time.  Etc.  You have to
add the timing so that the O/S and the user apps it runs executes a reasonable
number of instructions between interrupts, so that the results are fairly close
to what happens running on the bare hardware...

I can probably find a paper on the first one I wrote around 1973 for the Xerox
sigma 9 if you want.  Or at least I can cite a reference for it.

>>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...
>What? There are something like 3 formats for disk addressing: CHS, L-CHS, and
>LBA. Anyway, an emulator doesn't have to support everything to be compliant.
>Bochs doesn't support a particular BIOS function related to system memory
>probing. I've seen it boot Linux fine, and I've seen it boot Windows fine. (NT
>takes over a day to boot.)

There are _dozens_ of disk address formats.  The number of cylinders, heads
and sectors varies all over the place.  Basic drive operations vary all over
the place.  Parking heads.  error recovery.  "zones".  Etc.  All are important
to a true emulator.

>>> 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.
>Not usually. Windows is obviously the pervasive desktop OS. Most Windows
>programs are not compiled in GCC. The availability of GCC avoids that problem on
>many Unix platforms because users simply compile the program for their system
>and it works. Furthermore a lot of code which relies on vector instructions
>actually checks as it is supposed to.
>The K6 scenario you described is something akin to saying, "Wow, these Japanese
>cars suck because they don't look like the diagrams in my Ford manuals." A car
>is not required to have a gas engine or anti-lock brakes. The requirements for a
>car are quite lax with respect to the number of features that most cars have.

And no Japanese auto claims to be "100 percent equivalent".  And the two things
are so different that the comparison really doesn't match up.

Power connectors.  Cable connectors.  IDE disks.  All are good examples of
things that _are_ copied according to a precise specification, and they
interchange with no problems.  The CPU issue wasn't so clear.

As far as gcc goes, there are _far_ more gcc users than any other compiler
in the world.  So it is a standard of sorts, and freeware programs can run
into trouble for the reasons already given.

>it is with x86 chips, too. An x86 chip is not required to support vector
>instructions, cmovcc, etc. in order to be an x86 chip. Even Intel admits that.
>Intel removed the processor serial number from the Pentium 4. If your code
>required this feature without checking for it, it wouldn't even work on Intel

Note we are _not_ talking about "X86 chips".  We are talking about two
machines in a Comp-USA store.  One with an Intel PII, one with an AMD K6.
The AMD is sold as "compatible with the Intel box but faster and cheaper."
In this particular case, it is not exactly "compatible" and the cpu capability
stuff simply doesn't matter.  The average person writing computer programs has
no idea what the compiler is producing.  They do something like
"target=pentiumII" and that's it, and since the AMD is marketed as equal, the
program ought to run, but it doesn't.  And to say that unsophisticated users
should know that is unreasonable.  Most have no idea what any of this is all

>>>>>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.
>Yes, it is thick, but it documents many things such as PAE which are not
>required. The Crusoe does not support PAE. I don't recall if my Athlon does or
>not, but I don't think it does either.
>>>>>>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.
>That is an isolated case

I didn't say otherwise.  But it _was_ a case.  And it is easy to blemish
your reputation, it is very hard to clean it back up.

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