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."
...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 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.
Barring that, Intel could have simply browsed to AMD's web page and downloaded it themselves.
In Slashdot Utopia we could mark this article as "-1, Yellow Journalism".
"People that quote themselves in their signatures bother me" - athakur999
No, reverse engineering would be if they didn't know what the instruction set was, and they just applied inputs to AMD's CPU, and observed the outputs, and then made some suitable logic so that it would be the same for all the different input combinations.
Intel didn't have to do anything like that; they already had the documentation, all the specs, just had to implement it. Humans probably didn't even implement it. Geez. No reverse engineering here.
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.
It's very rare that the instruction set is the end of the story. There's alot of "gray area" that may or may not be documented and tons of undocumented instructions -- that was always the shtick with Intel. These gray areas need to be compatible as well. Hopefully AMD did things more straightforward.
Although I can't believe they wouldn't provide documentation to Intel, this is a HUGE win for them.
Religion is a gateway psychosis. -- Dave Foley
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.
We had several years of "DOStel".
Remember when 8086's and 80286's were made by everybody from Harris to NEC? DOS was the standard, and LIM 4 was the memory overlay spec. You could USE something goofy like NEC's 20MHz 8086 clone - when the Intel part topped off shy of 8 Mhz, and the 286 ran at 12MHz!
The whole kit was nearly "off-the-shelf", except for the BIOS. This was what Compaq "clean-room" reverse engineered with such care.
"Flyin' in just a sweet place,
Never been known to fail..."
But AMD's 286, 386, and possibly 486 were based on designs licensed from Intel. I believe at least some versions of the 286 were microarchitecturally identical (AMD as a second source of parts for Intel).
Yes but the point that article is making is that they didn't (and there seems to be pretty good proof of that as far as i'm concerned). Could the reason for the reverse engineering be that intel started work on it some time before the documentation became publicy available?
Anyways - Intel's behaviour is increasingly erratic.
In what way is Intel a follower instead of leader here? Everytime this subject comes up people here seem to conveniently forget that Intel had the Itanium 64bit chip out way before AMD. You can nitpick and argue that it is only used for high end servers but the fact is that Intel always planned for this to trickle down into the desktop space once they become cheaper and software is available. I doubt they have changed that plan. AMD (and probably IBM/Apple) simply forced them to come out with an interim solution that will go away once Itanium is ready for the desktop.
Yes, but intel needs something to differentiate the Xeon from the itanic i.e. they can claim you need to buy an intanic to get this high-tech, innovative intel security feature. Many corporates still don't buy AMD because there hasn't been big name backing until now. intel hopes that it can still market its way past some peoples' ignorance.
Stick Men
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.
Damn I'm glad you posted that. I was going to actually write something very close to the same. My next builds will all be AMD for various reasons listed here(and not), but Intel has been borking along for far too long.
Intel has become the underdog either refusing to look and devlop or thinking that 'name' will build and hold them marketshare. GM, Ford and Chrysler thought the same way back in the early 80's and it nearly killed all three. It may well kill Intel off if they don't smarten up.
Om, nomnomnom...
Two words: backwards compatibility. Nobody wants a processor that is not backwards compatible with current software, and nobody except OS programmers really cares what's inside the chip. If there was an actual demand for a better architecture, people would have switched to Alpha or PPC a long time ago.
So, it's not just a benefit to Intel and AMD, but really to everyone, even those who run Linux on x86, since it helps keep the hardware costs down.
You are being MICROattacked, from various angles, in a SOFT manner.
Intel also fell behind because they spent too much time in bed with MS marketing.
You are being MICROattacked, from various angles, in a SOFT manner.
Like I said, that's an economic issue. As much as everyone shoots (somewhat deserved) arrows at the x86 arch. it continues to exist because of the legacy programs out there. Whether or not a lot of the problems are more percieved than actual as both AMD (much to their delight) and Intel (much to their chagrin) are finding the marketplace wants the 64 bit cludge to the x86 arch. not something totally different, regardless of how good it may be.
The market has proven that you are wrong. You don't change instruction sets because the old ones aren't technically pleasing. Many have tried but none have succeeded in replacing x86 because they just haven't been compelling enough.
Assembly language programming in general is difficult. x86 assembly not particularly more so than others, but instruction sets aren't designed with assembly program ease in mind. Try programming EPIC in assembly or the first generation MIPS.
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
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.
Please tell me WHAT is wrong with x86? Ok, some people don't like programming assembly for it, others love it (as one x86 assembly fan put it: "there's a perfect instruction to do exactly what you want no matter what it is"). Besides which assembly programming for high-end microprocessors really doesn't make much sense anymore except in very odd situations.
No multi-purpose registers? x86-64 has 16 general purpose registers and 16 double-precision floating point registers (the latter capable of holding 2 DP or 4 SP floating point variables in vector mode if you so desire). Sure many other architectures have 32 of each type of register, but the difference isn't that significant.
10 years ago Alpha was stomping all over x86 in raw number crunching, especially in floating point. Now the two fastest processors in the world for integer stuff are x86 and two of the top 4 for floating point as well. Relative to RISC chips x86 is doing BETTER now than it was 10 years ago, not worse.
Evidenced by the volume of x86 ASM source, as well as like a million assemblers that are available for it? x86 ASM has its warts but it has some unusual advantages as well (complex addressing, lock primitives, free implicit flag calculations, etc) RISC and VLIW/EPIC have not been convincing alternatives to x86, so I would posit that at the very least its very *difficult* to develop an instruction architecture that's really superior to x86.
AMD released docs for the AMD64 stuff years back when it was x86-64.
2 _8366_7595 ~751,00.html
2 _8366_7595 ~7363,00.html
Year=1999 specs etc released
http://www.amd.com/us-en/Weblets/0,,783
Year=2000 _simulator_ released
http://www.amd.com/us-en/Weblets/0,,783
That's plenty of time. IIRC AMD even invited Intel to join the x86-64 side.
The issue is whether Intel needs a license. Maybe they indeed did a clean room implementation of AMD64. I'm not sure Intel can use that method to successfully avoid getting a license from AMD.
AMD64 should do some marketing and branding of the stuff Intel didn't implement- the times are right for it.
Actually HP selling Opteron servers is a bigger deal than this. It says many things. Maybe HP is feeling the 7 year itch, esp since the Itanic wasn't such a beautiful baby.