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.
At one time it was believed that the AMD/Intel cross-license on the x86 instruction set would cover the x86-64 extension. This was one of the reasons claimed for why Intel moved to Itanic. I believe that the cross license is how AMD got access to the 32-bit extensions to x86.
Can anyone confirm specifically that this was the case? I imagine that Intel may have reverse-engineered the opcodes, etc. just so they didn't have to go to AMD and ask for the documentation (which might have been announced in an embarassing press-release by AMD).
at least there will be a unified instruction set making it easier for developers.
having 2 defferent instruction sets would double the workload on developers as they would have to produce different versions for different instruction sets...not to mention OSes.
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.
... all major conflict is over?
They have legal cross-licensing agreeement ....
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 been trying for ages to get my hands on a crisp mp3 version of 'Animals'
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.
that's one hell of an accusation..
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?
I've been trying for ages to get my hands on a crisp mp3 version of 'Animals'
"Mmmmmmm. Crisp mp3 animals......mmmmmmmm"
Don't blame Durga. I voted for Centauri.
Good for intel. Now that it's law that any money invested in Intel R&D is really being invested in Everyone's R&D, it makes good sense to draw from the Everyone pool rather than thanklessly "contributing" to it.
The law is the real problem here. Intel should not be forced to share.
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
well... how old is AMD, anyway?
It's a freaking instruction set, and it's published {otherwise nobody would be able to write any software for it}. Anyone should be allowed to implement it if they design their own hardware to do it {or can prove that there is only one way to do it}. Frankly, I fail to see what the big deal is in all this. These multinational corporations are just taking their paranoia too far, and it's time somebody put a stop to it.
Je fume. Tu fumes. Nous fûmes!
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.
UNIX's man pages define its UI.
If independently implementing one is "reverse engineering", then so is the other. I don't think so.
Excessive IP-restrictions hinder competition, and slows innovation by stopping most derivative works. Corporate espionage actually helps both companies develop better products in this case. Capitalism and copyright monopolism definitely do not go hand in hand - because IP monopolies would nearly destroy every benefit capitalism has, namely, a competitive marketplace. Every copyright is its own monopoly, and monopolies are bad for competition. In the 1800's, The only way America managed to catch up with Britain's manufacturing industry is through direct copying of their techniques. And the fact that America did this did nothing to discourage innovation in manufacturing, in fact it had very much the opposite effect.
Repeal the DMCA!
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
if only AMD had been able to sneak in a few cyrix chips as their new easier-to-reverse-engineer edition 64bit chips....
there are only so many ways to extend a 32-bit arch to 64-bit.
There are enough ways that it would be unlikely for two companies to come up with the same solution by chance. The original 16 bit architecture had only eight general purpose registers, that number remained the same when it was later extended to 32 bits. AMD decided to put in more general purpose registers. So the first decission to make is whether to have 8, 16, or 32 general purpose registers. Next come the decission about to what extent you need the ability to access smaller parts of the registers. The original 16 bit architecture would allow you to access each half of the first four general purpose registers directly. There is no way you would allow direct access to each byte in 16 different 64 bit general purpose registers. But do you allow access to only the least significant 8, 16, and 32 bits in each 64 bit register, or do you allow access to higher parts in some cases. You need direct access to AH, BH, CH, and DH for backward compatibility. But that is not necesarilly required for any of the new 64 bit instructions. Then comes the decission about addressing modes, layout of opcodes, how to know how many bits an instruction actually operates on. With the 32 bit extension the later was determined by the CPU mode as well as an optional instruction prefix. Even though you want backward compatibility with 8 bit code, 16 bit code, and 32 bit code, the 64 bit code doesn't have to be backward compatible as there was nothing to be backward compatible with, so an entirely new instruction set would have been an option. But similarity with the existing 32 bit instruction set might be desired. That is a hell of a lot of decissions to make. And unless you make all of them the same, you will end up with two fundementally different and far from being compatible instruction sets. And even if all decissions I have talked about here have been made the same, some bitfidling still remains.
Do you care about the security of your wireless mouse?
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.
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.
Thx God they did. Would you immagine a world with two incompatible x86 64 bits extensions??
As the differences in the two architectures become more commonly known, Halfhill said that he believed a single version of a software program could be written to support both architectures, by avoiding all but the instructions used by both processor families
Why can't Slashdot editors learn how to...well, edit ?
-- You see, there would be these conclusions that you could jump to
Bill Siu, head of DPG (Desktop Products Group):
"Coming this year, more and more companies are employing hardware-based security. For example, the NX or the no execute feature will be available in our processors later this year."
Is the Itanium dead then?
I see hardly a mention of it!
Or maybe they just went to AMD and asked for (or bought) the specs.
Coder's Stone: The programming language quick ref for iPad
The responses to this article is hilarious. AMD have not used billions of dollars a new CPU that gets luke warm responses (Itanium+Itanium2). All the markethype from Intel concerning 64 bits for the unwashed masses, and here comes AMD showing the way. This time AMD is not playing the "catchup game".
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."
This is ridiculous. AMD gave Intel the cross license agreement. Intel got x86-64, AMD got SSE3. This has been very well documented on numerous occasions.
ExtremeTech hits a new low in yellow journalism.
They were making a chip with an AMD64 compatible instruction set. I would sure hope that the "instructions are similar".
there used to be a time, even among industry engineers and academics that slashdot was a respectable site with neat interesting news and discussion.
If you mention "so i saw this slashdot story and discussion.." today among those circles, you'll get a rolled eye and a snort.
-
So if AMD steals from Intel
As much as the slashbot religious fanatics hate to hear it, no one can deny the resemblance between the "Linux Desktop" and the industry and market leader, Microsoft Windows.
Linux is nothing more than a (poorly) reverse engineered version of Windows 3.1!
So Intel is playing catch up with AMD. Competition is a good thing. It's even better that Intel is conforming to AMD's specifications to ensure compatibility. Again, competition is good, cooperation is even better.
ah, the "derivative work". Maybe AMD should talk to SCO... 3 letters, lots of lawyers, they could sue everyone who buys a new intel chip for "use of a derivative work" or something.
Oh, never mind...
Reading the articles above I can only assume one or two things...this may in fact be the new dawn of intel, and AMD may have made the fatal mistake to make its own technology. I shall explain further and all shall be revealed.
AMD up until now has had the support of the desktop users, and the low end server crowd because of their price/performance ratio. Since it was a realatively low ratio people were able to get a lot of quick performance at a low price. AMD with the advent of their 64 bit technology, obviously behind Apple, has raised the price of their chips almost 4 fold.
Intel has always produced the top end of expensive processors, but they were always "achievable" even to the young new computer user. the disparity between the two has changed from a 2 over 1 situation (with intel leading) to a 6 over 2 (with AMD leading).....what's the problem you say? AMD hasn't proven, or developed their architectural structure. I would much rather purchase a pair of 2.8 ghz intels and run them on a dual processor board instead of running head long into the new 64 bit AMD's.
What is the big benefit for Intel? Well the dirty little secret of the server and workstation industry is that price rules, the differences in price and performance do not warrant investing in 64 bit technology....or for that matter any new technology because the industry has to develop applications (real and theoretical) to utilze the structure. Even though each processor company claims to have the lion's share of server users, and a slew of corporate "sponsors", one can not ignore the fact that most mission critical systems are still run on something Other than AMD.
To sum up the statements i've made; AMD doesn't have the track record to demand their current prices. Even more relevent; because Intel isn't "developing" the architecture they can finally start offering high-end new-age processors at ajusted prices. If anything can be seen it's that Intel may still come out on top, because AMD seems to be short sighted......of course in the end it always seems to be the end user who is short sighted.
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.
Just ask me. They stole code from my book to use in VTune. The code was copyright by someone else and I used it with permission, but it was clearly stated that that particular piece of code could not be used in a commercial app. Intel stole it line-for-line.
I never would have figured it out, but the guy who wrote the code disassembled VTune to find that the routines produced exactly the same binary code as his code (using Intel's compiler, I believe).
So, I wouldn't put it past them to reverse-engineer, legal or not, to acheive their means. Just my $0.02.
Having the architecture book laying around here somewhere I can tell you what he said is true.. HOWEVER the caveat is that the extra registers are used in all the branch prediction crap so it can potentially be working on things ahead of time that need another full set of registers without really relying on what's in the current set. at least that's how I understand it.
Its pretty sad that Intel has to reverse engineer ANYTHING from those unwashed scallywags over at Advanced Micro Devices.
Oh how the times have changed.
Mac OS X and Windows XP working side by side to fight back the night.
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.
fucking dumbass. "potentially" != "possibly"
completely different meanings.
The article is really speculation, not fact. Besides this is the computer industry where everyone steals from each other and tries to get rich off of lawsuits, because it beats working for a living.
Why even care anymore?
Professional Politicians are not the solution, they ARE the problem.
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.
You go ahead and misspell identical, AND then go on to bold it.
It's like a big pile of shit in the middle of a birthday cake with a candle stuck in it.
Of course you can do it to music, haven't you ever heard of "cover bands"?
If one gets the same product to me cheaper, I don't care what their logo is. Right now I'm sticking with AMD but if Intel can give me the same as AMD for less money I'll switch over in an instant.
Reverse-engineering is not illegal. 'nuf said.
I am sorry the Mods didn't get your joke I thought it was funny. Maybe it's an age thing.
Help fight continental drift.
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.
Just on GP.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
You and I benefit from this. AMD used IA32, now Intel copied AMD64. Cool.
In fact, I'm very happy Intel did not become a monopolist like Microsoft. A PC would cost much more than it does today...
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.
Compaq RE'ed IBM
Also, because they have the cross-licensing agreement, Intel can spend more of it's R&D dollars towards other areas in which they are heavily competing against another company and let AMD develop the x86 platform. AMD holds most of the PC enthusiast's loyalty so Intel not developing the top of the line first won't ruin or really even hurt Intel's market share.
This shows not how AMD is gaining momentum, but that AMD and Intel are extremely close to each other and the x86-64 extentions are not going to make any difference in the long run.
Compaq "reverse engineered" IBM's PC bios, opening the platform to all comers.
This is perfectly ok, and was upheld in court as being a perfectly OK thing for Compaq to do.
Fast foward to the end of the statute of limitations on industrial espionage.
Bill, our friend Gates, revealed that Compaq did not reverse engineer IBM's PC bios, but in fact paid Microsoft 300 million to simply hand it over.
Gates was tired of sitting under IBM's thumb and he knew that by opening the platform he would be opening up new markets for himself.
So... clean room reverse engineering is OK
And, industrial espionage is criminal unless..
You make so many Billions from your criminal act that you are above the law.
If voting were effective, it would be illegal by now.
As architectually Intel's Yamhill is no more a copy of AMD's Hammer than the K7's a copy of the P6.
Just because they use the same instruction set doesn't mean these 2 X86-64 chips are anymore related to each other than the Transmeta Crusue chip is related to the Pentium. Mind you the 2 different X86-64 CISC on RISC designs are probably going to be more related to each other than some X86 CISC on VLIW design, or whatever the Transmeta is)
Couldn't they use their market power to slowly remove the best features of AMD64 this way???
"Fighting terrorists with millitary might is like killing a mosquitor on your Dad's forehead with a rifle."
Uhh the load/store reordering is not a great solution and triadic operations are also usefull. And implementation issues are bigger impact, than what ever code issue people find or what ever architectural feature that impacts reordering is. The X86 makes implementors choose, between. Large instruction cache and wide execution, trace cache reduces the decoders while increases the code size, but wide execution without tracecache would be pain in the ass. And don't keep telling us lack of IPC, There is plenty of IPC available for out of order execution when you have plenty registers. And now I'm not saying 32 is best for today.... And don't say register renaming handles it, that problem it won't, it will alleviate its worst, the load/store reordering will alleviate the worst, now all this is handled by increasing control logic which already take over 90% of powerbudget, for inorder processor. Clean RISC architecture like alpha can get far more parallerism than an X86 can.
Why?
TWO dependencies to follow not 3! [flags], which helps with increasing OO execution, while flags renaming and all that crap, triadic operations are not 3rd dependency, two operands are after register rename 3 operands
More registers=allows keep more variables inside core, so that your memory ordering buffer with limited capacity for exeuction is free to handle the jobs not mangling temporary variables around.
X86:s complex memory rules, not ONLY the addressing modes, DO increase the costs for taking advantage of parallerising cache memory accesses. Keeping things clean make things easier, and doing great things possible.
Legacy modes[increase complexicty in Memory exeucion units and control logic] , partial register access=> more control logic, more trouble, in register handling, which leads less space for putting more parallerism in there.
With all these think that power comsumption is mostly from control logic EVEN with architecture that doesn't have the x86 hindrances.
Its no coincidence that alpha was 600Mhz with by FAR better clock for clock performance in 0.35 when it was last developed with full company focus on it. When x86 was at 300mhz. Yes it consumed as much power as 0.25 x86 when it reached at 600mhz but that happened long after that, and needed more advanced process and couple of revision to get there
[Alpha died because lack of marketing and making sales harder than necesary, and because bad management, and because its competitors where first in the market where compability rules.]
Emacs is good operating system, but it has one flaw: Its text editor could be better.
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.
They may have left off the NX bit, but I hear the the Intel designs added an extra Evil Bit to compensate.
Reverse engineering is legal. What's the big deal? Why did this even get posted?
Sorry, no prize...
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.