Slashdot Mirror
Intel Potentially Reverse-Engineered AMD64
icypyr0 writes "Tom Halfhill, an analyst for In-Stat/MDR claims that due to similiarities in the instruction sets of AMD64 chips and the new 64-bit extensions for Intel Xeons, it is clear that Intel reverse-engineered the AMD64. However, due to the fact that the new Xeon is not an exact copy of the AMD64's microarchitecture, Intel has not broken the law. This very tactic has actually been used by firms such as AMD in the past to catch up to Intel."
So reverse engineering is not a problem in this case. In fact, it's not unlikely that AMD simply handed them the documentation.
Intel has cross-licensed X86 do death. I believe the terms of the deal state that Anyone can use x86, but any improvements they do to it are free for Intel to incorporate.
------- "From bored to fanboy in 3.8 asian girls" ----------
This is correct, the NX bit is missing from the Intel implementation
Normal people worry me!
Give up on the MP3, go for AAC.
The secret to getting modded up is to allways say i've got karma to burn in your sig..
No, not really. The NX flag is dealt with by the memory controller, which is not incorporated into Intel's processor (but is in Opteron/Athlon64), so it's hard to say whether it will be supported by Intel. That is, until the specs for the north-bridge are out.
:-)
But given how MS bragg it as a security measure, I can take bets
Stephane
Sure, Intel is known, like Microsoft, to do underhanded things, but these are all gray areas... marketing tactics, etc. But when it comes to a clear-cut IP thing like this, there's no way they're going to want to put themselves at risk like this.
Besides: (1) Intel and AMD have all sorts of cross-licensing things in place, and (2) there are only so many ways to extend a 32-bit arch to 64-bit.
Intel's "IA32e" is fundamentally an Intel design, with 64-bit extensions. I think IA32e is basically a Prescott (or later) core. Intel and AMD go about their CISC-front-end-to-RISC-core in quite different ways with quite different results in terms of efficiency, etc.
So, the bottom line is that I'm sure, given that they do execute the same instruction set, that there will be MANY similarities, but they will be either accidental or necessary similarities.
Also, the lack, or inclusion, of LAHF and SAHF being a "smoking gun" seems to be an overly strong conclusion. LAHF and SAHF were included in the 8086 to ease transition from 8080 code and as such, have been somewhat arcane. Although they have their uses, dropping them has been probably been frequently considered over the years.
Given that the instruction sets are compatible, you don't need to do much investigation to figure out that they have looked at AMD's x86-64.
Apparently, there is still some confusion about whether the instructions sets are compatible or not, and people such as Linus has been critisizing Intel for trying to hide the fact that they are indeed compatible by giving the instruction set another name.
When it comes to licensing of technology, AMD and Intel has had cross-licensing agreements since the seventies, and there has been roumors for a long time that these has included x86-64.
Intel pulled an AMD.
So reverse engineering is not a problem in this case. In fact, it's not unlikely that AMD simply handed them the documentation.
But reverse engineering isn't "Handing them the document," as you put it. They have the right to produce a chip which uses the same instruction set (x86-64) within their chip, but they have to find a way to build it themselves...unless they reverse engineer the design of the chip itself...happens all the time...Z80 ring a bell? AMD did the exact same thing with the Intel 286, 386, and 486...took Intel's chip and reversed the design...until they finally came out with their own design of the 5x86 architecture, the K5. The K5 still used the x86 instruction set, but executed it with their own engineered design. So, maybe this is a good sign of Intel now being the follower instead of the leader.
No, not really. The NX flag is dealt with by the MMU, which is part of the processor.
Yep, Intel sure suffered A Momentary Lapse of Reason.
no, it's handled by the mmu, which is on chip (and has been for many years on many different chips). the memory ctrler does nothing but access the ram chips.
Bill Siu, head of DPG (Desktop Products Group):
"Coming this year, more and more companies are employing hardware-based security. For example, the NX or the no execute feature will be available in our processors later this year."
This is ridiculous. AMD gave Intel the cross license agreement. Intel got x86-64, AMD got SSE3. This has been very well documented on numerous occasions.
ExtremeTech hits a new low in yellow journalism.
Lots of good points there... AMD has been doing very well lately, though honestly I think they've been doing most of it by *not* trying to innovate, and just trying to do what makes the most sense. Example: Athlons from tbird through barton are all pretty much the same, just with die shrinks, cache increases, and bus/multiplier differences. In that period Intel's put out what, 3 significantly different P4 cores, and invalidated a couple of socket types. I think that lack of extra worthless effort is a big part of what keeps Athlons so inexpensive, and yet AMD has still provided good performance just doing the conventional things.
However, where I disagree with your assessment is about the dropping of the P4 architecture, going with a Pentium M derivative. I think thats the best move Intel can make at this time, and that while it might be a bit confusing to consumers, they're going to develop some very good chips as a result. I've always felt that the P4 was a stupid design to begin with, that only stayed competitive through hacks and ingenuity on the part of Intel's engineers. Now that they're going back to a good architecture, we could very well see another dynasty like the P6 core presided over.
Although there were rumors about an Intel Yamhill 64-bit x86 part for many years, they didn't announce an 64-bit x86 architecture extension until February 18, 2004, and it was announced sheepishly as a very minor point in a press release rather than amid great fanfare as AMD had done. Intel still has not released any product incorporating this extension. Thus they've had more than 3 1/2 years to develop their own 64-bit x86 based on the AMD specifications. No need whatsoever for reverse-engineering. In fact, reverse engineering would have taken much longer, because they would have had to wait to get their hands on working AMD silicon.
Well, the way CPU performance works today isn't really intuitive. A modern CPU can slice each opcode into several independent primitive operations and run each of those independently. In fact, it can reorder the suboperations from a variety of opcodes and do the work as it can be done, delaying for later the primitives that depend on long-latency things like data from cache. It can also execute many operations after a branch before it knows that the branch will be taken, and throw away all of those results if the branch gets mispredicted. The CPU may be simultaneosly working on dozens of opcodes at any given point in time.
To support this craziness, the CPU uses "register renaming", which allots dynamic assignments for the user-visible registers from a bank of generic hardware registers. At any one time, you may have several versions of "EAX" simultaneously exist in the CPU; these represent the value of EAX at different logical points in the program code (some of the values may later be found to be useless because of speculative execution).
So what the programmer thinks of as a bottleneck of loading and storing EAX a couple of times in succession may turn out not to be a bottleneck at all if the values are logically independent. The instructions may be reordered so that both loads of EAX exist at the same time, regardless of what one would assume from looking at the linear opcode sequence. In this case you get to simultaneously use more registers than what you can see.
While its hard for assembly programmers to keep this straight, compiler writers can emit code that is aware of the CPUs behavior to take advantage of these features as much as possible. The X86 instruction set is a kind of bytecode abstraction; the compiler and CPU can mutually understand that there are ways to transcend the apparent limitations of that visible architecture.
The bottom line is that register pressure is an issue, but register renaming in the X86 helps to mitigate it. Moreover, AMD's 64-bit extension adds lots of new programmer-visible registers, further reducing the problem. The real challenges going forward with current CPU designs today are improving branch prediction with ever-deepening pipelines, increasing cache size as the CPU speed continues to outstrip DRAM speed, and managing power consumption as gate leakage and transistor count increase. All CPU architectures need to deal with these issues, X86 and RISC included.
(Itanium was meant to be a new approach to the branch-prediction issue, pushing the intelligence to the software compiler; it hasn't been a resounding success. It also really pushed the cache size by including monster caches, and this has been the main reason for its reputation as an expensive power guzzler. The CPU core really isn't that big or complex.)
sorry for posting as Anonymous. :-)).
When AMD only started to loudly talk about x86-64, my friend - u-code designer - told me in a private conversation that "...the management is worried, I was asked to look into the possibility of implementing u-code extensions of those new instructions. I'll look at their public specs today. After all, there's not much else to be changed except the u-code".
I guess he did - but we never spoke about that later.
The point is:
1. Intel was preparing an answer to x86-64 as early as AMD started to talk about it.
2. Intel was quite understandingly taking a wait-and-see approach to that - no one would pull the plug on an already available product, no matter how well it's selling, in favour of competitor's hype. They only started taking real marketing steps when it was obvious that x86-64 is getting accepted and didn't want to lose this market completely.
3. The implementation is 100% in-house using only AMDs public specs. The uArch was ready before Athlon64 launch, for just in case, and they started marketing it as early as it was clearly no-other-choice situation. C'mon, give Intel some credit - why steal from AMD if there's plenty of in-house talent available? They even made Merced work (after only 8 years
I'm not sure AMD-64's instruction set is all that useful at this point in time owning a new Athlon64 3200+ myself. I find the Cool'n'Quiet function more impressive. At idle I have a core cpu temperature of 31 Celcius! A tie to my motherboard chipset due to it CPU clocking down to 800mhz when idle. If you ask me that's a much nicer innovation at this point.
Do you know what these two instructions are? They are for compatibility between the 8086 and the 8-bit 8085 processor. They load and store the flags into AH in the same bit positions as the 8085 so that SAHF+PUSH AX has the same format as pushing the Accumulator/Flags pair onto the stack on the 8085. Since the 8085 is an extension of the 8080 and 8008 architectures it makes these instructions compatible with the flags register format of the first 8 bit processor ever produced!
There were actually tools to automatically convert 8085 code to 8086 that used these instructions.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.