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.
...in other words this isn't news.
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.
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..
IANAPCU (PC user), but maybe they're doing this for compatibility?
Think about it. PCs are almost struggling for good 64-bit compatibility. Chances are that they got a clue and decided to do what Apple-hardware did with PowerPC many many years ago.
Remember, Motorola & IBM both had PowerPC standards. Why shouldn't Intel & AMD learn how to get along as well?
If they just copied the instruction set to be compatible, then created their own microcode to implement the code, how is that really considered 're-engineering' ?
Now if they tried to duplicate the internals as well, id give you that it would be in that case..
But sounds like Intel did nothing more then clone the functionality of a black box, using their own techniques.
Or perhaps I'm just nitpicking on terminology..
---- Booth was a patriot ----
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.
Next week: GNU/Assembler. . .
You are not the customer.
To quote from the article: While exactly copying a processor's microarchitecture would be illegal, creating a compatible product through the use of an original "clean room" design is legally protected.
So, if what Halfhill says is true, how did Intel make it illegal for VIA to make a chipset for the P4? How did Intel prevent AMD from making chips that would fit in Socket 370 and Slot 1? That was the reason for the "socket wars" - to prevent AMD from making compatible products.
Thats complete BS if Intel can get away with this and AMD had to suffer for it.
-- If we don't stand up for our rights, now, there will be no right to stand up for them later.
Does that mean that what each AMD64 machine instruction does is not fully specified? How are we supposed to program for the AMD64 then, by using only the machine instructions that are clearly explained? Intel just missed an opportunity to invent a new behavior for the badly-explained instructions, publish a "complete instruction set handbook" for the AMD64, which people will use because AMD's handbook is unclear/incomplete, and have everyone wonder why their "AMD64" code only works on Intel.
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.
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
Hollywood actor Ben Affleck has been witnessed cashing a multi million dollar paycheck around the time of the chip's release. Film at 11.
Mother, do you think they'll like this sig?
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.
Gee, can I do this with music, and then the RIAA can't touch me?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
Or perhaps Mr. Halfhill is confused about what the term "reverse-engineering" means. Specifically, it is reconstructing specifications and design information from a finished product. Designing a new, compatible product from published documentation is not in any sense reverse engineering.
It's not clear that Intel would have broken the law even if they HAD made an exact copy of AMD's microarchitecture.Microarchitecture per se is not protected by law, though aspects of it could be patented. But Intel and AMD have patent cross-licenses, to that is not an issue. A specific mask layout may be protected by copyright law, but it's quite possible to copy microarchitecture without copying mask layout.
It is also possible that AMD may have provided the x86-64 architecture documentation to Intel under NDA well before the public release. The very name, "x86-64", was suprisingly vendor-neutral. I suspect that AMD only renamed it to AMD64 after they believed they had been unsuccessful at convincing Intel to produce compatible processors. Intel denied for years that they would offer a 64-bit extension of any kind for the x86, despite the widespread rumors to the contrary.
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.)
So reverse engineering is not a problem in this case. In fact, it's not unlikely that AMD simply handed them the documentation.
Reverse engineering is NEVER a problem. The very concept that it MIGHT be is recent - and driven by propaganda from the software industry.
Historically, industries have reverse engineered nearly everything: Cars, looms, what have you. (Auto compaines, for instance, have entire DEPARTMENTS to disassemble and reverse-engineer their competitors' products.)
You can patent an idea - which gives you a lock for a number of years on using it in a commercial product or process. But that immediately exposes it, and releases it to the public domain once the time is up.
Alternatively you can keep it secret, and hope the secret stays secret and nobody reinvents or reverse-engineers it. But once the cat's out of the bag you have no protection whatsoever. If you show the secret to an employee or business partner, and they leak it or use it beyond the limits of the contract, you can sue THEM and enjoin them against further disclosure. But if the "secret" has spread beyond catching, or if it is rediscovered/reinvented or discovered by examining a product you sold, tough luck!
Software companies have tried to stretch trade secret via ELUAs claiming you're a "business partner" rather than a purchaser of a product, and thus contractually forbidden to do reverse-engineering. And they've tried to stretch copyright similarly, claiming you have to copy it to use it to reverse engineer and that's forbidden by your license (first-sale doctrine be damned). But (except for the DMCA, which has yet to be adequately tested) there's essentially no foundation in law for these claims.
Or at least that's how I (who ANAL) read it.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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.
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.