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."
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
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
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.
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
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.
The real crime isn't the reverse engineering. Its that both intel and AMD are still supporting the x86 architecture. x86 is like a dog that should have been put down a long time ago. I remember 10 years back looking at VAX architeture and being amazed that intel would continue without multi-purpose registers. It truly is a pain to do any assembly programming on the x86. The only excuse that intel had to continue with the x86 was that optimizing compilers weren't good enough for them to reimplement a RISC processor. The times have changed, and so should their microprocessor designs.
Half of Engineering is reverse-engineering. And it's not always a bad thing.
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 ----
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
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
{cough cough cough} Itanium. And look how well that turned out.
There are options out there my friend (Power, Sparc, ARM... I happen to adore my power based macs). Its not like anyone is shoving the X86 arch. down our throat. Intel, in fact, has been trying to shove the good ship Itanic down the high end's throat and the high end told him to piss off. Face facts, technology doesn't always trump economics. Get over it (and go buy a Mac if you hate the x86 so much).
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.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
The problem is that all windows apps which people take for granted as working since 1994 would break unless software (slow) or hardware (bloat) emulation were integrated into the new systems. Windows could be recompiled by MS, but what about Jim the Tech's miricle tool made in '96 and unsupported ever since?
So?
The 99.9% of people writing apps in any langauge as abstract as C or higher don't have to worry about the CPU architecture. If it compiles and runs these languages at a price/performance ratio favorable to other CPUs, then nobody sould have a problem with it.
The true runtime architecture of an X86 CPU (and most RISC chips as well) has been mostly unfathomable to humans since the Pentium Pro came out. The X86 instruction set is just a backwards-compatible abstraction that is used to logically specify what needs to be done. The chip transforms these instructions to something completely different at runtime. For example, X86 chips already do have dozens of the "multi-purpose" registers you're pining for; you just don't see them at the visible instruction set level. When you do "assembly programming" on a modern CPU, you're not much closer to the real hardware than you are writing in C.
So? Even if they did reverse-engineer something, what's wrong with that? Without reverse-engineering, IBM would probably still be producing the only PCs, and the computer market, Internet, and many related technologies might not have grown to the extent that they did.
Besides, they could have bought the instruction set documentation and built a similar processor based on that. Just like you can read the Windows API manuals and make libraries that provide the same functionality.
However, that's largely irrelevant since it's not the same architecture anyway. This is reverse engineering in the most literal sense - taking a known set of responses and going backwards from it to a design that will yield the desired result. Analyzing the blueprints wouldn't be reverse engineering at all; it would actually be making a direct copy.
NB: YMMV. IANAL. Take the above with a grain of salt.
Maybe they do have more multi-purpose registers (I don't believe you 100%), but if you cannot access them via assembly code, then the compiler can't see them either. Then they aren't very useful. RISC architectures are much better.
There's a rather large difference between having a set of programmer's manuals and having the transistor-level blurprints of the logic implementation.
And if you did have the transistor level blueprints of the logic implementation, what exactly would you be reverse engineering?
Reverse engineering is harder than working from published specs. It is establishing specs from the actual chip, then building it themselves.
AFAICT, the Intel stuff is no more "reverse engineered" from AMD64 than Linux is "reverse engineered" from Unix. It's simply another implementation of the spec.
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.
You think Itanic will ever be ready for the desktop? I'd bet that the AMD x86-64 wouldn't even really exist today if the Intel Itanic had lived up to something near it's marketing hype. The Itanic is a dog. It came out extremely late, and with a low clockspeed, which allowed Intel's other processors to beat it in nearly all benchmarks, had limited OS support, and provided little or no 'bang for the buck'. Even the 'early adopters' had no reason to get Itanic chips. It would've been nice to get away from the i386 instruction set, but Intel messed up any chance of that happening.
I used up all my sick days, so I'm calling in dead.
So if you can make a CPU which emulates x86 code as fast as the competition, then go right ahead and try.
The key is that software writers (other than assembly) don't care about hardware; they care about maximizing the number of customers. Customers want cheap, fast and good software and hardware. If most customers currently have x86, and it would cost more to develop for other platforms (think beta-testing on every type of hardware), then software makers can minimize costs, and expediate release dates by supporting only one platform. Since x86 is the historical basis, customers can mostly only purchase x86 software, so they maximize their utility by purchasing x86 hardware, and the cycle repeats.
To introduce incompatible (or innefficient at backward emulation) hardware, customers will have a minimial initial set of commercial software that will run on it. So they won't purchase the new hardware unless their work-station/desktop will run nothing other than core utilities (OS MP software, for example), and thus there is no market for software writers.
OS writers may love hardware enhancements, but they don't make the bulk of software demand. Video games, office software (ACT, exchange, visio, photoshop, Nero, etc) are limited to very vew platforms (MAC/x86), so you're giving up a lot, even with newer software.
Apple had enough monopolistic pull in the MAC software world to make the hardware transition. Windows / Intel do not have such pull; how long did it take to migrate from DOS -> NT? And the irony is that OS/2 was not serious competition, so what did MS have to lose by going full protected mode win32 in the early days of win98? The reason is that they were trying to maximize their revenue stream, and I trust MS, of all companies, to know exactly how to do so.
Here is what I would have suggested. AMD64 adds an entirely new operating mode of execution. This is identical to the Itanium x86-mode, EXCEPT that AMD kept the x86 instruction format. This reuses the I-decoder, and more importantly, garuntees compatible instruction formats. The Itanium SUCKS at running x86-code because there is an impedence mismatch between x86 and EPIC logical instruction units. The Itanium solves totally different problems than x86-assembly is asking the CPU to solve. If Itanium requires smart compilers talking it's exact langauge to operate efficiently, then running x86 is like being given driving directions in greek for a road in France when you're in New York. The only difference is that you happen to have the same logical output when you're done. To make matters worse, x86 compilers do all sorts of bizzar re-arrangements of code with the full knowledge that they're maximizing the concurrent execution and minimizing delays FOR THE PENTIUM IV. These bizzar arrangements are just line-noise to the Itanium which can in no way take advantage of the re-ordering, and often time is spend decoding and excecting the equivalent of noops.
The point is that, any radical divergence, even by AMD64 from the core macro-op concepts are going to have likewise impedence mismatches for running legacy IA32 code. Still, I don't know why they didn't make all instructions 32bit aligned, and simply have seperate instruction decoders for 64 and 32bit instructions. They could have preserved the logical units, and given a HUGE performance boost.. But I haven't read enough AMD-64 details to know the motivations in this respect.
-Michael
All that crap like Register Renaming is just a huge hack!
The ONLY reason we have it is because of the crappy x86 architecture (4 registers! GAH!).
The majority of 'advancements' in x86 CPU design have mostly been ways of getting round the stupid design of x86 rather than actual advancement.
CISC->RISC instruction decoders, register renaming, and all the other 'intelligence' of the modern x86 CPU are just ways of getting round the limitations of x86.
As an architecture, Itanium is excellent - Unlike x86, where the only real way to speed things up is ramping clock-speed, Itanium leverages parallelism which is much easier to speed up (Adding another CPU currently requires a lot less effort than finding new ways of throwing electrons down increasingly thinner tracks).
The Itanium CPU itself is as thick as a brick compared to K7 and P4, but this is the KISS principle, and IMHO, very clever.
The CPU doesn't need all that die-enlarging baggage: All the intelligence - branching, instruction interleaving, and what have you is all delt with by the compiler, which can evolve unlike the CPU. This would potentially allow you to compile a program again later in life to give it a performance boost!
However, x86 has a single thing going for it which is why nothing - not Macs, Itanium, Amiga or anything will dislodge it any time soon:
Its momentum.
x86 is so damned prevailent that it is impossible for AMD or Intel or anyone to break away from it. It's success will mean that we'll be saddled with it for a loong time, despite the universally accepted notion that it is insanely out of date and, in fact, crap.
If Itanium ever comes to the desktop, Linux is the one thing that can save it: The source-code nature means that programs can just be re-compiled (with tweaking) to work with it and you're sorted.
The Windows world is screwed 'tho - decades of binary-only software will immediately be useless, lost. Its only means of survival would be via. emulation.
This ain't gonna happen, which is why we're stuck with x86 and why Itanium will be stuck with Sparc et. al. in the high-end where custom programs are written as a matter of course.