Computer Chess Club Archives


Search

Terms

Messages

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

Author: Matt Taylor

Date: 16:22:50 03/04/03

Go up one level in this thread


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:
>>>>
>><snip>
>>>>>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_
>>>large
>>>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.
>><snip>
>>
>>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
>>ISA.
>
>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,
>interrupt
>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.

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.

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.

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.
>><snip>
>>
>>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
>>>study
>>> 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
>>>version...
>>
>>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
>full
>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.

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

>I'd bet doing I/O emulation would be a good week's work to get something that
>emulates
>various types of disk hardware, various formats for CCHHSS, interrupt delays,
>channel
>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.)

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

>>>>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
>>>reference
>>>PDF I mentioned at Intel and download it.
>><snip>
>>
>>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
>about
>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
>Programming
>Guide".
>
>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
>>>selling
>>>_more_?
>><snip>
>>
>>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
>"You
>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
>compatible."
>Then that person is going to assume that software that runs on one will run on
>the
>other.  This is not always true, particularly in the "freeware" world, where
>Crafty
>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.

>>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
>brand
>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
>>>has
>>>a problem.  That was my _only_ point.  It happened with the K6 and CMOV for me.
>>>I
>>>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
>>>weren't.
>><snip>
>>
>>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.
>
>
>>
>>-Matt



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