Intel Threatens To Revoke AMD's x86 License
theraindog writes "AMD's former manufacturing division opened for business last week as GlobalFoundries, but the spin-off may run afoul of AMD's 2001 cross-licensing agreement with Intel. Indeed, Intel has formally accused AMD of violating the agreement, and threatened to terminate the company's licenses in 60 days if a resolution is not found. Intel contends that GlobalFoundries is not a subsidiary of AMD, and thus is not covered by the licensing agreement. AMD has fired back, insisting that it has done nothing wrong, and that Intel's threat constitutes a violation of the deal. At stake is not only AMD's ability to build processors that use Intel's x86 technology, but also Intel's ability to use AMD's x86-64 tech in its CPUs."
Bah hah hah, silly idealist.
The two-party system is here to stay in American politics and the x86 stranglehold.
I, for one, welcome our new strong ARM'd overlords.
It is by my will alone my thoughts acquire motion; it is by the juice of the coffee bean that the thoughts acquire speed
People who? Do you really think that 99% of the computer users even know what x86 means?
End anonymous moderation and posting on
Intel and AMD like to squabble about licensing every few years. Probably in an attempt to broker a deal that is even more favorable than the last. They usually spend some time posturing in court, bare their claws a little, then settle with a new cross-licensing agreement. If Intel gets too pushy, the feds start staring at them REALLY hard. Which tends to make Intel fall in line.
Strictly speaking, Intel's argument is pointless. Yes, their deal is with AMD. But AMD's foundry only manufactures the chips, it does not design them. (Unless I somehow misunderstood their fabless plan.) Since the fab creates the chips on behalf of AMD, the licensing is not violated.
That's my 2 cents worth, anyway. I'm not a lawyer, but I doubt one would make many more comments without viewing the legalese between the two companies.
Javascript + Nintendo DSi = DSiCade
Maybe I'm missing something, but how can the x86 architecture itself be subject to copyright? Isn't the protected property not the publicly documented instruction set, but the implementation thereof?
Slashdot: Playing Favorites Since 1997
-They- being the PC manufacturers that sell most PC's these days. -They- being the OS vendors who would be into a world of hurt trying to support every differing configuration of the x86+ based architectures....
Since x86_64 is a superset of x86, would this mean AMD couldn't even sell x86_64 based chips either?
Bye!
If x86 dies, which it is in the process of doing, Microsoft will port Windows to run on SPARC, ARM, PPC, whatever comes next. Microsoft has gotten where it is by being good at business, and being good at business does not consist of pushing a dying platform that it has no vested interested in. Windows has been ported to other architectures before, and is inherently portable.
I heard this argument when it was "people will stop using windows".
It's nice to think about and all, but wake me up when it actually happens.
Intel will definitely work this out. They're almost forced to license x86 to prevent being labeled a monopoly. Many believe the only reason they licensed it in the first place was to prevent legal action by the justice department. With a competitor making similar chips it's hard to claim they strong-arm computer manufacturers into using their products.
Developers: We can use your help.
New hotness = Lawyers on retainer!
I for one, will miss the Megahertz Myth race.. But hey, it might go crazy when AMD has a GPU as the Vector CPU in the computer, and Intel has to sell a 63-bit processor.
I guess it will be exciting to watch new developments again.. Seems they've gotten a little to comfortable with each others positions lately..
What are we going to do tonight Brain?
Since x86_64 is a superset of x86, would this mean AMD couldn't even sell x86_64 based chips either?
Funny thing is that AMD licensed/agreed to share their x86_64 arch back to Intel.
So essentially it's:
"I'll let you play with mine if I can play with yours."
Now a 3rd party (loosely affiliated with AMD) is playing with Intel's x86, and that wasn't part of the agreement.
I say don't drink and drive, you might spill your drink. Before you get behind the wheel just stop and think.
Yes. You said it yourself: x86-64 is a superset of x86; the architecture is reliant on instructions from the legacy set. No license to the legacy set, no dice on building the superset.
But that's okay, because there's no way Intel would ever pull the trigger. This is just corporate posturing to get a better crosslicensing agreement and a slice of the Foundry's pie. They'll fight it out for a couple more weeks and then a "settlement" will be reached behind some closed doors, probably with the Foundry agreeing not to mint over N non-x86 chips and some cash changing hands in whichever direction.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
HAHAHAHA.
I'm on my way to buy SUN stock right now.
Oops, maybe not.
OK, I'm off to buy stock in HP!
Errr...
I'm going to purchase some DEC stock!
Oh fooey.
"I'll let you play with mine if I can play with yours."
Man, if I had a nickel...
Quit jabbering on the phone while driving. You are not that important.
sounds RISCy.
Windows is still maintained on Itanium; both it and the Alpha port could run x86 binaries at close to native (or, at one point in the Alpha's lifetime, faster.) I'm no Microsoft fanboy, but I don't think they're stupid.
Windows on PPC... Then Microsoft will tout how much faster PPC is than x86 based processors, and the world ends in an infinite loop.
I traded all my mod points for these magic beans.
It IS just a matter of passing a different CPU flag. MS discontinued the MIPS, PPC, and Alpha versions because there was not only no demand for it, but the few people who bought it tied up lots of MS customer service time bitching that X86 programs didn't run on MIPs/PPC/Alpha.
Windows is no more married to X86 than Linux or OS X. In fact, I can tell you where to get a fairly modern Windows Kernel running on a PPC chip in pretty much any electronics store: The XBox 360.
The NT kernel was designed from the ground up to be portable. The only real reason it's currently only supporting X86 is because that's the only place there's any sort of demand. If X86 dies (And it won't. AMD and Intel both have lots to lose, though AMD more than Intel here), Microsoft will port over to PPC (Or whatever), throw on an emulation layer, and probably take the opportunity to break a whole bunch of crappy stuff in Windows that's maintained simply for backwards compatibility.
Intel has no intention of preventing AMD from making x86 chips, because they know they'll be unable to manufacture any of their own chips as well (with x86-64 licensing coming from AMD). This is purely meant to ensure that anybody who might come along and acquire the foundry business doesn't wind up trying to produce their own x86 chips. Or at least, I'd like to believe such...truthfully, I wouldn't put it past Intel to just be making a money grab here.
Either way, holding AMD in violation of their agreement means they would effectively forfeit 64-bit licensing rights as well, and that makes no sense for them.
You'd probably swallow it by accident.
The two-party system is here to stay in American politics and the x86 stranglehold.
And operating systems and phone companies and potato chips and cereals and sexes.
Virtualization makes the host arch less important, but we generally don't run a virtual instance of a different hardware platform. The reason is that there's a really high penalty of either recompiling (with the possibility of bugs) or full instruction emulation which makes runtime performance horrrrrrrible.
Most modern virtualization systems will run the guest OS almost natively using CPU's virtualization extensions to make the magic happen without much overhead.
Try running Windows on an ARM or PPC x86 emulator and see how long it takes before throwing your hands up in slowness frustration.
Bye!
This is probably just high stakes gambling. AMD has little to lose. (I say that as an AMD share holder looking at my $2.49 stock price.) Intel has more to lose if they have to redo the 64Bit code. According to the reading, if Intel wins, they get rid of AMD, and become a defacto monopoly having to face US and EU anti-trust regulators. If AMD wins, they get to go along as before and Intel can't sell 64-bit CPUs that people want.
Basically I bet AMD's lawyers are saying "Go ahead make my day." Given the above even if Intel wins in court, they lose.
Think Deeply.
Don't blame me, I bought a Cyrix!
Feel free to mock me, however.
The tiny problem with Dubai is its money isn't made in oil, but in banking and tourism. One good indicator of how fucked its economy is, is that they're passing a law banning journalistic discussion of the economy.
And all the new building projects are being shelved as well.
http://www.kippreport.com/kipp/2009/01/21/what-freedom-of-speech/
But that's okay, because there's no way Intel would ever pull the trigger. This is just corporate posturing to get a better crosslicensing agreement and a slice of the Foundry's pie.
RTFA carefully.
By alleging that AMD is violating the agreement, Intel can pull the trigger on AMD and still use AMD's patents.
Because of Intel's threat, AMD is saying that they can pull the trigger and still use Intel's patents.
It's an interesting game of chicken that they're both playing.
[Fuck Beta]
o0t!
No, their not. Abusing a monopoly position is.
I can certainly patent sexwidget and have a perfectly legal monopoly as the only company in the world producing them. Only if I try to force people to do other things not directly related to my sexwidget in order to get access to them is it considered abusing my monopoly status. In other words, if I try to force retailers to purchase other products like sexfoo & sexbar as a requirement for being able to sell sexwidgets, I'm abusing my monopoly.
as long as it doesn't SPARC an idea.
When all else fails, try.
Misconception. RISC may be more elegant but it is less efficient. Translation and register renaming take up tiny amounts of die compared to the instruction cache savings of x86.
I wish Slashdotters would stop with the incessant "x86 sucks" mantra. You're all fools.
There's plenty of crufty old instructions in the x86 ISA; no modern compilers generate them though, so no one cares that they're there. They take up a couple pages in the ISA manual I guess. The die area it takes to implement them is totally, completely insignificant. They're either in microcode (along with a bunch of other really useful instructions) or the hardware already exists for some other reason.
There's plenty of crufty segmentation and weird ways of laying out memory and whatnot; no modern OS uses that though, so no one cares that it's there. And again with the ISA manuals and some transistors. And there's plenty of modern paging and flat memory models and whatnot too.
AMD and Intel both know how to make good, fast, and (relatively) small hardware to decode variable-length x86 instructions. Yes, of course an x86 decoder is bigger (i.e. more expensive, more difficult to implement, etc.) than a RISC fixed-length decoder, but again, no one cares because we already know how to do it fast enough and cheap enough. Check out an x86 die photo sometime; most of it is cache. Probably about 1/50th is decoder.
And CISC-style+variable-length instructions get you a smaller code footprint and thus better instruction cache utilization vs. what you'd get with a fixed-length instruction stream. Examples: common ops get shorter instructions, there are more flexible addressing modes, more flexible sources/dests within a single instruction, you get one x86 instruction (no more than 15 bytes) to do what would take multiple RISC-style instructions (probably more than 15 bytes).
Sure there's the crufty x87 floating point stack. But there's also the shiny new SSE/SSE2/SSE3/whatever instructions, and modern compilers can exclusively use SSE/SSE2 to do the exact same thing (-mfpmath=sse does it in gcc). And again, die area for x87 FP stuff isn't a big deal since a lot of the hardware is shared with SSE.
ISA extensions have been added to cover all the newfangled SIMD stuff and virtualization you can want. AMD64 covers 64-bit stuff. And 64-bit stuff gives you extra registers too (8 extra integer, 8 extra SSE for a total of 16 each), which is great and a nod to the large number of registers that RISC machines give you.
In short, what the hell is everyone bitching about?
Aside from the problems mentioned here, there's also the other issue that as soon as they exposed/permitted the native core instructions to be used, people would use them and they'd have to support them forever .
(Disclaimer: I don't know that much about chip design, and some bits of the next paragraph may be misleading, half-remembered or misrepresent Intel's motives.)
IIRC, during the x86's long development (or mutation), Intel added some features because they could, and because it seemed like a good idea at the time. Some of those features were never much used, or turned out to be not such a good idea, or were rendered mostly irrelevant by design changes in the next generation. Still, once they'd been included they had to support them for evermore, because they couldn't risk breaking compatibility with code that *did* use them.
Now, I assume that the current chips' RISC cores was designed because it suits Intel's current way of implementing the x86-emulation/execution (and as the other guy said, wasn't designed for end-user/program use). If Intel come up with a smart, new and totally different design/architecture, the way things stand, they could simply replace it with a different core that used different microcode instructions, and change the x86 "wrapper".
If Intel had exposed the microcode of the previous generation, they'd either have to stick with the old core architecture, or include it as emulation. Except because it was emulated, it probably wouldn't run as fast, and old (i.e. *existing*) programs that used the old microcode would probably run slower on the new chips. So they'd be forced to stick with the old architecture.
(Essentially it's the hybrid software/hardware equivalent of (e.g.) someone exposing the implementation details of a Java class simply because they "can" or "someone might want to use it". If in future they want to redesign that class in a more efficient manner, they have to worry about code that used the old implementation's internal workings.)
All because they exposed some microcode functionality which wasn't even meant to be anything more than a "black box" implementation detail- unsuitable for general use- in the first place.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
I'd like to see a chip that can run in a x86 'translated' mode and a 'native' RISC mode, much like was done with 32bit/64 bit.
Already ready to use. The Transmeta Crusoe processor does this on the fly. Of course, now they're owned (or is that pwned?) by Novafora so your guess is as good as mine whether this will survive.
My office has been taken over by iPod people.
The ARM netbooks and embedded devices are coming and there's nothing Microsoft or Intel can do about it except adapt and compete. The time when you could defeat a good technology with an evangelist is long gone since the public now knows evangelists are just shills for hire. The day a MS rep could derail a Linux deployment with a sneer has passed. Sorry Enderle, your day is done.
Intel will choose to compete and they have a good start because they started years ago. As the Atom die shrinks and gains SOC capabilities, its power requirements will come down. Maybe not to ARM levels, but to an acceptable level faster than ARM can bring their performance up to acceptable levels for a good user experience. Microsoft will choose to use the tools they have, and fail to adapt. That's what they do. They can't grasp a market that's abandoned the need for them. It's alien to their corporate culture. After they've failed in the market they'll buy an ARM OS vendor and try, but that's five years hence. and they'll buy five of them badly and integrate them poorly and we'll laugh at their ineptitude here.
Ultimately Intel will win this one but there will be some interesting side stories and products between now and then. Microsoft will lose because they choose not to port to the interesting new platform Linux runs on already, and so when the channels merge again they will have lost share. By then low power devices might be most of the share, at least for end user devices.
Help stamp out iliturcy.
Intel can shut down AMD's ability to use the X86 technology without giving up the AMD-64 technology if they can show that AMD defaulted on the agreement.
AMD can use the X86 technology and prevent Intel from using the AMD-64 technology if they prevail.
A court is going to have to measure this. The smart money is on a settlement but barring that Intel will win.
Let us meet here again in seven years, when the matter is settled.
Help stamp out iliturcy.