Author: Matt Taylor
Date: 10:33:50 03/04/03
Go up one level in this thread
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. >>>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. 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. >>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. >>>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. 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. >>> 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. -Matt
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.