Slashdot Mirror
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
... stupid intellectual property bullshit.
There is a war going on for your mind.
-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!
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."
At stake is money and corporate posturing.
This is just another day of corporate King Of The Hill.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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?
Long live StrongSparcPC_x64! Poor Microsoft, how on earth would they sell Windows 7?
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
But the big draw of windows is the inertia of 1,000,000 one-off apps that businesses have written. Microsoft would be scared of people moving to another architecture just because if people were making a (painful) switch anyway, they might look at the alternatives.
-Bucky
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.
Something like that, but not perfectly symmetrically. While x86_64 is well-enough established that it would be inconvenient for Intel to have to go back to x86 and build a new, non-derivative extension with similar capabilities, it would be less of a problem for them than AMD losing the rights to use x86-anything.
Given that Intel and AMD don't have serious competition for desktop PCs right now, its possible that the a result that hurts Intel a lot but AMD more in the short term could benefit Intel in the long term, though really the intent here is almost certainly to get concessions from AMD on the basis that Intel may be able to prevail in court, and AMD stands to lose more if the agreement is terminated; it is extremely unlikely that Intel's goal is to terminate the agreement.
"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.
Not trying to sound like a troll here, but x86 should have been retired decades ago. It designed in a totally different era and was never intended to scale well and its been a series of hacks to get it to do so. ( it was impossible to predict where we were going back then, the cpu industry was far too immature )
Sure, they have done wonders keeping it moving, but its long since time to start over with a clean architecture.
My preference would be MIPS or SPARC inspired, but thats just me, either way its time to move on/up.
---- Booth was a patriot ----
Funny that you should say that, because if the world ends at the infinite loop, we'll all be running Mac OS X.
We have virtualization now - If I can run a legacy app in a dos box, who cares what the actual hardware is?
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
Hmm, I wonder if the reason for this is Intel is scared of Globalfoundaries? If I'm not mistaken, the folks who bought the foundry from AMD are the same folks who are building in Dubai. You know the place where money flows like water and they're willing to waste billions to build custom islands? If that's the case, it is possible that AMD could be ramping up their production and process dramatically which would negate any gains Intel has. AMD also seems to have a more market friendly history with other companies than Intel has. Perhaps this is Intel's attempt to gain a monopoly before their ship sinks?
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.
Like heck.
It would force both AMD and Intel to pull their chips temporarily.
The only thing Intel could sell is the Atom (32 bit only), and the original version of the Core (again, 32 bit only).
Yeah ... they'd still have a product to sell on the market, but a staggering amount of their products (most of the Core line) would simply stop.
Likewise AMD would still have the Geode and other chips to sell, but their desktop/server line would have to stop.
MS would probably continue okay (I hear Win7 runs okay on the Atom and old Core processors), but it would mean that we'd be back at 32bit limits for things like memory.
The groups that would be hurt the most (beyond AMD and Intel)? Computer retailers like Dell and Apple (whose products would have to be redesigned), and the American computer economy as a whole (I'm sure you'll be able to find AMD and Intel chips made in China that would keep shuffling off the assembly line just fine).
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
Agree, ARM has been gaining grounds due to it's low (as none) power consumption when idle. So long backward compatibility tough.
You'd probably swallow it by accident.
99% is a really high target man. I doubt that 99% of computer users know where the power switch is.
Maybe you should look to 5% or 10%
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.
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!
Is it time for AMD to make some more steps in throwing out the heritage from x86? Yes an x86-64 CPU can run in backward compatible 16 and 32 bit modes. In fact they still start up in 16 bit mode from which they have to be switched to 32 and then 64 bit mode. But the 64 bit mode could have done more to remain backwards compatible with old 16 and 32 bit code, however at the time AMD made the bold decision to allow some old software to not work in the 64 bit mode. Maybe it is time to take another step in getting rid of the heritage. How about making it possible for the CPUs to start up directly in 64 bit mode? That would be a natural next step towards completely getting rid of the backward compatible modes. The 64 bit instruction set can hardly be called the same instruction set as the 32 and 16 bit ones, first of all it is 64 bits, and it also has more general purpose registers. Those are clear distinctions from the old instruction set, and it was created by AMD, so I don't think Intel could prevent them from using it. I know you can run 16 and 32 bit code in the 64 bit mode, and a lot of people still use it (at least the 32 bit code), but I still think we are at the point where the 64 bit AMD ISA is more important than the 32 bit Intel ISA.
Do you care about the security of your wireless mouse?
So, if the AMD cross-licensing agreement goes away and there isn't serious competition for Intel in the x86 world, I'd expect Microsoft to start supporting alternatives.
Windows already ships by the million on PowerPC hardware: XBox 360.
Before the XBox 360 came out, the development environment that Microsoft was supplying was Windows ported to Power Mac hardware (G5 I believe).
AMD x86 processors aren't going away, though. This is intel just flexing its muscles, spreading FUD to get AMD's share price down and to scare consumers away from its chips.
All of these big technology companies have patent cross-licensing deals with each other. You'd better believe that intel can't survive without AMD's patents, and AMD can't survive without intel's, or Sun's, HP's, Microsoft's, TI's, FreeScale's... and so on.
Stick Men
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.
There's a lot at stake.
It appears from the snippet of Intel-AMD agreement posted that I've seen (at Tech Report, in comments) that The Foundry Company is perfectly fine under the agreement, as AMD has a certain share of the company, and it formed from AMD's assets.
So Intel might be playing with fire. They lose this, they've just lost x86-64 - and Itanium is dead due to minimal investment in the past 5 years, and this year is when 64-bit x86 will hit the common desktop with Windows 7. More likely that AMD would get that license really loosened if they won and a bunch of money, but you know, if they're backed by ballsy Arabs...
If AMD lose, Intel could have all sorts of fun.
I'd like to see this go a bit father.
Today's chips, at their core, look a lot like RISC chips. They do a lot of work to hide that, translating x86 ops to native ops. 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.
this is, admittedly, a much harder task to accomplish, but exposing a more efficient RISC mode would drive OS vendors to migrate to that. With a bit of careful juggling and VM technology the chips would allow legacy code to run while exposing the more efficient native modes to software that took advantage of it.
Such a shift would take time, but so is 64bit.
Oh well, I guess I'll go back to the idea lab and keep on dreaming.
md5sum
d41d8cd98f00b204e9800998ecf8427e
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).
Just don't upset the ALPHA overload and you should be fine. Otherwise, he met send you on a one way trip on the Itanic.
Not all virtualization requires hardware extensions. In fact, VMware was doing it long before Intel and AMD added virtualization support to their processors. VMware pulled this off by doing dynamic translation, where the virtual machine monitor would transparently rewrite native x86 into virtualized x86 code. For the most part this was just doing a straight copy, and perhaps rewriting some jump addresses. Privileged code that runs in the OS kernel had to be rewritten as something equivalent that would run fine in an unprivileged process.
This really isn't so different from running .NET or Java code. The code starts out compiled to a virtual instruction set, and the JIT compiler translates this on the fly to something that can run natively on the CPU.
This is also how Rosetta worked in Mac OS X to run PPC apps on an x86 processor. XBox 360 does a similar thing to run old XBox games, since the 360 uses a PPC processor but the old XBox was x86.
Sure, you take a performance hit in doing this, but the apps generally get rewritten to run natively eventually, and the ones that don't end up being old enough that they run faster on modern hardware even with the extra translation layer.
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.
RTFA carefully.
You must be new here...
That's not true. Windows NT has run on Mips, i860, Alpha, PPC and Itanium. None of them ever had even 1% of the market.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.