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