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.
Good, because compatibility is everything.
I haven't read the article (this is /.), but i would have expected they reverse engineered, or read the documentation for AMD64 to implement their x86-64 cause it's apparently very nearly the same ISA.
Intel and AMD have a broad patent cross licensing agreement, so it's not a big deal.
Need a Catering Connection
...Isn't it true that they left out the NX (no-execute?) bit, thus causing some compatibility issues?
---
Never criticize religion on Slashdot. You will be modded down for "Troll" no matter how factual it is.
I don't get it. If they all do it, then this is a bit of a 'none story' right?
"This very tactic has actually been used by firms such as AMD in the past to catch up to Intel."
Of course. Although don't forget cross-licensing deals as well e.g. Pentium.
The fact that Intel went to all this work simply shows that AMD made the better decision with it's architecture.
In my vocabulary "to reverse engineer" means to find out something internal, hidden and protected. The article talks about "reverse engineering AMD instruction set", which is obviously public. This is called "copying", and has nothing to do with "reverse engineering"
MSDOS: 20+ years without remote hole in the default install
I have not read the license but maybe deliberately breaking the compatibility may not be an option, and god forbid having your "innovations" stymied. [/sarcasm]
Help fight continental drift.
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" ----------
The big story here isn't that Intel has done anything "wrong", but they've done something that they haven't done in the past... something that AMD used to do when they were trailing behind Intel.
Now the shoe's on the other foot. AMD has taken one of the signs that used to say Intel was the market leader.
AMD will have the last laugh here. Turns out they embedded a Pink Floyd album in the code of AMD64 (a fair-use copy, as AMD had previously purchased the album). When Intel copied the code and put it in their chip, it was all AMD needed for a little call to the RIAA to pay a visit to Intel's house....
Don't blame Durga. I voted for Centauri.
This is ahrdly reverse engineering. This is Intel building an ISA to a specification laid down by AMD. Just like Transmeta executing IA-32 code, or like Lindows looking like windows.
AMD didn't even have silicon before Intel started building 'yamhill', so by definition of the term, it is impossible for Intel to have reverse engineered.
https://www.accountkiller.com/removal-requested
Intel employee A: Here's the spec AMD gives us. Use it.
Intel employee B: Yee Hah!! I've almost figured out how they do this last opcode!
Intel employee A: Yeah, it's on page 183 of this. Read it.
Intel employee B: Leave me alone!! Specifications are for weenies! I'll reverse engineer it. You can keep the specs, thanks.
I've seen some people suggest that it was actually a "copy" of something AMD already made public, and not really a true attempt at reverse engineering. But even if it was reverse engineering, so what? Of course they haven't broken any laws! There's nothing wrong with reverse engineering. How many times has /. come out to defend reverse engineering (DeCSS, PlayFair, bleem!, Connectix's Virtual Game Station)?
If the little guys can do it, the big guys can do it, too. No double standards, please.
Tuck
Tuck's Journal.
Half of Engineering is reverse-engineering. And it's not always a bad thing.
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.
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.
Yes, reverse Engineering is the norm, happens all the time, blah blah.... The real story here is that, for a change, Intel did it to AMD instead of the other way around. Or, as the article puts it, "Intel's decision, however, clearly places AMD in the role of market leader. " Maybe a tad too grandiose of a statement, but it's at least in the same ball park.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
It looks like Intel might be pulling the same trick as MS did on Java. By not implementing two instructions (LAHF and SAHF) might be trying to break compatibility ever so slightly. The question is whether they'll be able to fragment the market as well as Microsoft did.
I suspect that they won't be able to, as compatibility and optimization lies a mere recompile away. However, if they were going to be 100% binary compatible, the results would be most interesting. Just imagine the carnage from head-to-head competition between Intel and AMD. While they have competed in the past, they have always had slightly different offerings. Their different feature sets were needed by different people. If these were identical, then AMD and Intel would be on the same battleground with the same featureset.
It would be an interesting battle indeed. AMD's low cost and efficiency (and overclockability) versus Intel's brute-force and high-speed (and marketing). I suppose we'll have to wait for the next round for anything along those lines though.
You must be new here.
You must not know how to read slashdot ID #'s.
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.
because Intel and AMD have, and recently renewed, a share and share-alike licence for each others technologies. They do this because it would hurt them both were their chips incompatable
Completely irresponsible and mindless work here.
This is truly a sad, sad state of affairs when stupid, unresearched yellow journalism like this makes the front page of Slashdot. We have known for *years* about the cross licensing of patents between AMD and Intel. It's been reported ON THIS SITE.
I normally don't like to flame the editors, but this is nearly unforgivable.
Goodbye Karma.
As for Intel's processor, I haven't heard good things. I saw an article on either The Register or The Inquirer that pointed to an article in c't about the Noncona (English thanks to Google) that Noncona is in trouble. According to the article in c't, a beta tester described the performance of the chip succintly: "It sucks." The article also states that HP has decided to only use Opteron chips, so perhaps it knows this fact too. The article doesn't say why (although it speculates that it's only emulating parts of the 64 bit instruction set). The article also has some info on some other things.
All in all, after all their foot dragging, I've lost interest in Intel. I'm worried that it won't perform as well as an Opteron. I'm worried it will be a blast furnace (Opteron's aren't cool by any means, but they look only luke-warm compared to Presshot). And I have read speculation (which I believe) that Intel is going to move to an integrated memory controller (like the Opteron) for performance reasons. Let's not forget that Intel is pushing a whole new form factor (BTX) just to help controll heat (or at least that seems to be it's major contribution to the world). AMD used to look like a "me too" company to me, making knockoffs. But over time (starting with the Athlon) I've been watching them and I no longer see them as an "also ran", they seem to be the REAL innovators these days.
AMD vs. Intel:
There are tons more. I saw an article on it the other day. Intel is not on sure footing, if you ask me. Between the problems above, the trend to sub $500 computers, and just AMDs gaining reputation, Intel could be in trouble. It has recently admitted that it can't continue to use the P4 and is going to build it's future chips off of it's mobile chip because they can't keep speeding up the P4, it's not worth it.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
if only AMD had been able to sneak in a few cyrix chips as their new easier-to-reverse-engineer edition 64bit chips....
While working at Intel in 2000-2001 it was well known that there was a "finders fee" of $5,000 for each 'hammer' you could provide the company with. In fact there was even a spooky looking site (complete with spy vs spy logo) on our intranet listing what all the finders fees were for various 'items' under development by our competitors.
needless to say I was a little surprised when I saw this...but not to surprised.
Granted, it doesn't mean AMD is the "market leader" (normally measured in $$$), nor even the overall technology leader, but being copied by Intel sure bolsters AMD's image.
Everyone knows how slashdot ID #'s work.
In a now famous episode of short sightedness, CmdrTaco said, "Slashdot will never need more than 640K IDs," and determined that slashdot IDs would count down from 640K and stop when they hit 0.
Your ID of 15628 indicates both that you are new here, and that the end is near.
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 think it's clear to everyone this isn't reverse engineering. They are copying the instruction set, which in most peoples opinion, is no sin. It's of mutual benefit if the instruction sets are compatible, and there is a cross-licensing agreement in place between the two companies to ensure this.
What I think is that Intel is now saying, "Oh crap, we missed 2 instructions!" Now do they quickly add them in to maintain the compatibility, or create this wiered instruction set that is always going to be known as "Intel's Mostly Compatible AMD64 Instruction Set". I would like to see them add the 2 instructions in, just to make it easier for software developers.
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.