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."

26 of 476 comments (clear)

  1. Re:if they do that by Anonymous Coward · · Score: 5, Insightful

    Bah hah hah, silly idealist.

    The two-party system is here to stay in American politics and the x86 stranglehold.

  2. Re:if they do that by hwyhobo · · Score: 4, Insightful

    People will just look harder to find alternatives

    People who? Do you really think that 99% of the computer users even know what x86 means?

    --
    End anonymous moderation and posting on /.
  3. Business as usual by AKAImBatman · · Score: 5, Insightful

    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.

    1. Re:Business as usual by Chris+Burke · · Score: 3, Insightful

      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.

      It may not be that easy. The Intel/AMD license agreement, for all its notoriety, is completely confidential and thus nobody knows exactly what is in it except for a small number of people at both companies. Despite that, it has long been suspected that part of the agreement is that AMD would not manufacture more than a certain % of its chips at a 3rd party fab, which FoundryCo -- wait, it's GlobalFoundries now, slightly less stupid name -- would almost certainly count as once fully spun off.

      Strictly speaking, though, nobody outside the upper echelons knows. The only thing I'm 100% certain of is that AMD thought about the cross-licensing agreement when they came up with the idea for spinning off the fabs, and would not have done it if they thought it would cost them their license. But of course companies can differ in their self-serving legal reasoning, and who knows maybe they knew they were taking a chance and felt that the global anti-trust inquiries and the threat of losing AMD64 licensing would keep Intel playing ball?

      --

      The enemies of Democracy are
    2. Re:Business as usual by 0xABADC0DA · · Score: 3, Insightful

      If Intel gets too pushy, the feds start staring at them REALLY hard. Which tends to make Intel fall in line.

      One remedy used in the past for monopolies is to take it's patents and trade secrets and place them in the public domain. Even if Intel were to win a complete victory, they could end up losing it all.

  4. More... by Jaysyn · · Score: 3, Insightful

    ... stupid intellectual property bullshit.

    --
    There is a war going on for your mind.
  5. Re:if they do that by ADRA · · Score: 4, Insightful

    -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!
  6. What's really at stake by davidwr · · Score: 3, Insightful

    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.
  7. Re:if they do that by the+linux+geek · · Score: 5, Insightful

    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.

  8. Re:if they do that by nametaken · · Score: 4, Insightful

    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.

  9. Intel will license it by truthsearch · · Score: 5, Insightful

    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.

  10. Re:if they do that by ciroknight · · Score: 5, Insightful

    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
  11. Re:if they do that by Tiber · · Score: 5, Insightful

    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.

  12. Re:if they do that by the+linux+geek · · Score: 4, Insightful

    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.

  13. Re:if they do that by Fulcrum+of+Evil · · Score: 3, Insightful

    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"
  14. Re:if they do that by Grave · · Score: 5, Insightful

    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.

  15. Re:MAD by powerlord · · Score: 3, Insightful

    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.

    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.
  16. Re:Poor Microsoft by nonicknameavailable · · Score: 3, Insightful

    with FUD

    --
    Mendacem Memorem Esse Oportet
  17. Re:if they do that by ADRA · · Score: 4, Insightful

    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!
  18. Re:Maybe Intel is scared of globalfoundaries? by TinheadNed · · Score: 4, Insightful

    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/

  19. Re:if they do that by TubeSteak · · Score: 5, Insightful

    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!
  20. Re:if they do that by kasperd · · Score: 3, Insightful

    Since x86_64 is a superset of x86, would this mean AMD couldn't even sell x86_64 based chips either?

    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?
  21. Re:if they do that by turgid · · Score: 3, Insightful

    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.

  22. Re:if they do that by frieko · · Score: 4, Insightful

    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.

  23. No. by AcidPenguin9873 · · Score: 5, Insightful

    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?

  24. Re:if they do that by Dogtanian · · Score: 4, Insightful

    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).