Author: Matt Taylor
Date: 14:03:32 03/07/03
Go up one level in this thread
On March 05, 2003 at 22:56:50, Robert Hyatt wrote: >On March 04, 2003 at 21:55:55, Jeremiah Penery wrote: > >>On March 04, 2003 at 11:23:17, Robert Hyatt wrote: >> <snip> >>>Har-de-har-har. There. I laughed. Happy? Now tell me what precise >>>specifications Wal-Mart >>>has to follow in order to compete with another store? Precisely how fast they >>>have to serve >>>a customer. How many square feet for this department, how many for that? >> >>So tell me precicely how many cycles AMD processors have to execute each x86 >>instruction, how much cache they must have, how many transistors they should >>use, and the core voltage they must use in order to be "compatible" by your >>definition. > > >The precise specification is that written by Intel, which is my point. A >program with timing loops is bad programming, but it still works on Intel >boxes if it is developed there. It won't work on something that behaves >differently. But, back to the _real_ point. A cpu that supposedly competes >with the PII should be _compatible_ with the PII at any level of abstraction >a user might want. All the way up to the output from a compiler that targets >the PII processor with an executable. The K6 failed that test and led to some >bad vibes. And what about the old turbo switch? Old 8086 programs with timing loops failed on the 386 & 486 whether they were Intel -or- AMD. Time -always- breaks such bad code. The K6 is compatible with the Pentium 2 at the levels of abstraction that are defined in the spec. That means that the K6 says, "No I don't have cmovcc." The Pentium is likewise compatible with the Pentium 2 at this level. This is the way things have been for the past 10 years. <snip> >>If you made patented advances in Crafty, which required licenses for the >>opponents to use, your window would be eternity if you wanted it to be. That's >>the situation Intel is in. > >And??? The window is there for the leader whether there are licensing issues >or not. Nobody buys a Pentium 4 because it has SSE 2. Nobody bought the Pentium 3 because it had SSE. Nobody bought the Pentium 2 because it had MMX (though the Pentium was later extended to include MMX). Intel was actually forced to allow AMD to implement MMX. I don't think Intel is holding out on AMD with SSE because they know they'll get sued again. Likely AMD simply hasn't bothered to implement it yet. Likewise hyperthreading isn't even a window of opportunity since AMD patented a similar feature in '99. Hyperthreading is a buzz word to increase sales, but it isn't a window of opportunity. >>>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. >> >>AMD _can't_ implement SSE (or whatever) unless Intel licenses it to them. If it >>was that big of a deal, Intel wouldn't license it at all. > > >Why are we off onto SSE? It hasn't been a problem. Cmov _was_ a problem >that was documented and mentioned in many discussion groups. Who says cmov is a problem? You're the only person I've talked with who thinks this. >>>>Here's something funny. The x86 ISA requires that when an FPU exception occurs, >>>>a certain instruction can read what instruction caused it, and where it >>>>happened. Pentium4 can't do this. So can we call the P4 incompatible with x86? >>>>:) >>> >>>Doesn't matter. PIV is compatible with PIV. It is the "leader". It doesn't >>>matter what they >>>do, what matters is can the followers do it too so that they can sell??? >> >>If you have software that depends on that feature, which worked on EVERY x86 >>processor EVER, you'd call the P4 buggy. P4 claims to be completely backward >>compatible (You even claimed earlier it was compatible with the old 4004), but >>it is demonstrably not in this instance. You demonize AMD for claiming >>compatibility with the K6, and use buggy software as a demonstration that the >>claim is untrue. But when the P4 is not even backward compatible (which is FAR >>more important) it's somehow ok? > >I haven't "demonized" anyone. I pointed out a specific problem that I had to >deal with. One, a bad processor (K5). Two, an incompatibility issue between >two supposedly "equal" processors, the K6 and the P2. If that is "demonizing" >then I guess I did it, but that was not my intent. It simply points out that >Intel is setting the "standard" because a program runs on _all_ their PII >processors, and when it doesn't run on a competitor's processor because they >_chose_ to leave something out, that can be an issue. A broken program, yes. I can write code that runs only on K6/K7 (3DNow) and then cry that Intel chips are broken, but the reality is that my program was broken. Alternatively, I could write SSE 2 code and run it on a Pentium 3 and watch it blow up because the SSE 2 encodings reuse MMX instructions, and the P3 (and Athlon) incorrectly decode the instructions. I could then point a finger at Intel. Actually, they do deserve that one. <snip> >AMD apparently thinks it is more profitable to follow rather than to design >a _good_ architecture that would catch on. Heaven knows the X86 ISA is a piece >of trash. Kludge piled on top of kludge. But it is what we have right now. AMD knows it is easier to sell something with existing infrastructure where software needn't be rewritten. >How can they innovate when they have to faithfully follow the intel ISA? 3dnow >is _dead_, for example. Its dead because the ISA is intel's and nobody wants to >write a piece of code that is AMD-only, because the intel side of the market is >_way_ bigger. No, 3DNow is dead because SSE is supported by both Athlon and Pentium 3/4. Even after Intel had released SSE on the Pentium 3, -many- programs offered support for 3DNow in addition to SSE. If Intel solely controlled the ISA, then why haven't they broken 3DNow? They have carefully avoided the 0F 0F opcode map which is where the 3DNow opcodes (and other extensions) reside. Also, AMD added extensions to CPUID. If you refer to the documents I cited recently, any CPUID vector with the MSB set is an "extended function." Intel now supports these in the Pentium 4. -Matt
This page took 0 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.