7 ms·

Intel's always maintained some of the leading fabs with technology usually a fair bit ahead of their competitors, but it is losing an entire segment of the proc

Intel's always maintained some of the leading fabs with technology usually a fair bit ahead of their competitors, but it is losing an entire segment of the processor design space. It is pretty big news that instead of continuing to make their own plays at these markets, (which haven't worked out) they're allowing others to ship their own ARM designs using their fabs. Intel's competitive advantage has always had a lot to do with the integration and bundling of world class fabrication technology and their processor designs pushing each other forward. They've increasingly broken this cycle in the past few years, with the final demise of tick-tock and the continued number of devices which opt for ARM. It's another in a series of developments that are reshaping the processor market and slowly moving Intel from a dominant position to a supportive one. There's still a large number of brilliant engineers and amazingly competent people there. I wonder when they're gonna start really fighting for their future.

lnanek2 10y ago
"fighting for their future" is often shooting themselves in the foot in my experience. A company I was at agreed to transition off of ARM to x86 for the next cost down revision of their embedded product. During the negotiations Intel promised libhoudini ARM translation support. Once we were committed and many weeks down the design path with development boards they broke their promise and refused to provide libhoudini. It was a really terrible position to be in because Intel was forcing us to get all our very expensive third party software relicensed in x86 versions, and we had no money for that. Honestly, we would have been a lot better off just sticking with ARM instead of buying Intel's lies. In the end, if Intel had provided an ARM option, though, they would have been a competitive solution at least instead what they were which was just a bad idea. So this insistence on fighting to get companies on x86 is not helping them necessarily.
- djcapelis 10y ago
  I agree their existing attempts have been disheartening and hard to watch. I don't think fighting for their future necessarily involves keeping x86 as their only chip architecture. I think that right now their "fights" and entries into these markets have mostly involved trying to keep the world from changing, not really fighting to survive. Less new and interesting strategies, more taking out old dusty x86 cores, polishing them up a bit and shoving them into the packages and market segments where they aren't dominant. This is their fault at this point. It used to be that without x86 compat, you had an uphill battle. They don't have that high ground anymore. The fact that companies like yours were more locked to ARM than other options should be a huge, amazingly large warning sign for them. I think what they should have done was the work the RISC-V team already started. I'm not sure they have the right architects to do it there though, frankly. The last time they tried to start a new architecture they really messed up on keeping it simple and providing clean hardware. They didn't recover confidence after Itanium and I think there was probably a lot of "Never Again" sentiment (probably rightfully so) both inside and outside the company. But I think at some point it is going to become clear to them that they don't have any option but to try a move that desperate and risky again if they want to be a dominant player in the processor design business in the future. Who knows if they'll actually get it right though. I probably would bet against it and would expect them to shift more and more towards a legacy designer (see also IBM) with substantial fab tech and capabilities that remain world class even if the processor design part loses most of the device markets.
- gameshot911 10y ago
  What ended up happening? Did Intel breach any contract they had with you guys?
- mariuolo 10y ago
  > During the negotiations Intel promised libhoudini ARM translation support. Once we were committed and many weeks down the design path with development boards they broke their promise and refused to provide libhoudini. How come this wasn't put in the contract?
MawNicker 10y ago
I'm amazed at the features they've crammed into x86 without breaking compatibility; Definitely impressive. That being said haven't they perverted the whole industry with this tactic? It seems like we ought to have switched from CISC to RISC. From a purely technical perspective at least. Microcode just seems like a run-time mini compiler. If it were just part of the actual compiler wouldn't that save power and heat? Could it hurt performance in some circumstances? Does CISC have any technical merit at all? I would love for this to have been motivated by something other than their x86 patents.
- erichocean 10y ago
  > Does CISC have any technical merit at all? Object code, in some cases, can be smaller. That's why modern RISC ISAs like RISC-V include a "compressed" instruction set option, to combat the object code size disparity with CISC ISAs.
  - Unklejoe 10y ago
    I've heard of that. I believe it's used on some automotive computers (Bosch GS19 transmission controller comes to mind, which I think uses the Freescale MPC500). I wonder how it works. If the opcodes can all be compressed, why not just make them smaller to begin with? I guess I always thought of opcodes as being enumerations of "commands".
    - wolf550e 10y ago
      RISC instructions are all the same size in bits to achieve fast decode speeds. Thus you must choose between 32bit instructions or 16bit instructions. ARM supports both, including function calls from one to the other.
      - plasticchris 10y ago
        This must have been solved, thumb 2 (https://en.wikipedia.org/wiki/ARM_architecture#Thumb-2 https://en.wikipedia.org/wiki/ARM_architecture#Thumb-2) mixes 16 and 32 bit instructions.

lnanek2 10y ago

"fighting for their future" is often shooting themselves in the foot in my experience. A company I was at agreed to transition off of ARM to x86 for the next cost down revision of their embedded product. During the negotiations Intel promised libhoudini ARM translation support. Once we were committed and many weeks down the design path with development boards they broke their promise and refused to provide libhoudini. It was a really terrible position to be in because Intel was forcing us to get all our very expensive third party software relicensed in x86 versions, and we had no money for that. Honestly, we would have been a lot better off just sticking with ARM instead of buying Intel's lies. In the end, if Intel had provided an ARM option, though, they would have been a competitive solution at least instead what they were which was just a bad idea. So this insistence on fighting to get companies on x86 is not helping them necessarily.

djcapelis 10y ago
I agree their existing attempts have been disheartening and hard to watch. I don't think fighting for their future necessarily involves keeping x86 as their only chip architecture. I think that right now their "fights" and entries into these markets have mostly involved trying to keep the world from changing, not really fighting to survive. Less new and interesting strategies, more taking out old dusty x86 cores, polishing them up a bit and shoving them into the packages and market segments where they aren't dominant. This is their fault at this point. It used to be that without x86 compat, you had an uphill battle. They don't have that high ground anymore. The fact that companies like yours were more locked to ARM than other options should be a huge, amazingly large warning sign for them. I think what they should have done was the work the RISC-V team already started. I'm not sure they have the right architects to do it there though, frankly. The last time they tried to start a new architecture they really messed up on keeping it simple and providing clean hardware. They didn't recover confidence after Itanium and I think there was probably a lot of "Never Again" sentiment (probably rightfully so) both inside and outside the company. But I think at some point it is going to become clear to them that they don't have any option but to try a move that desperate and risky again if they want to be a dominant player in the processor design business in the future. Who knows if they'll actually get it right though. I probably would bet against it and would expect them to shift more and more towards a legacy designer (see also IBM) with substantial fab tech and capabilities that remain world class even if the processor design part loses most of the device markets.
gameshot911 10y ago
What ended up happening? Did Intel breach any contract they had with you guys?
mariuolo 10y ago
> During the negotiations Intel promised libhoudini ARM translation support. Once we were committed and many weeks down the design path with development boards they broke their promise and refused to provide libhoudini. How come this wasn't put in the contract?

MawNicker 10y ago

I'm amazed at the features they've crammed into x86 without breaking compatibility; Definitely impressive. That being said haven't they perverted the whole industry with this tactic? It seems like we ought to have switched from CISC to RISC. From a purely technical perspective at least. Microcode just seems like a run-time mini compiler. If it were just part of the actual compiler wouldn't that save power and heat? Could it hurt performance in some circumstances? Does CISC have any technical merit at all? I would love for this to have been motivated by something other than their x86 patents.

erichocean 10y ago
> Does CISC have any technical merit at all? Object code, in some cases, can be smaller. That's why modern RISC ISAs like RISC-V include a "compressed" instruction set option, to combat the object code size disparity with CISC ISAs.
- Unklejoe 10y ago
  I've heard of that. I believe it's used on some automotive computers (Bosch GS19 transmission controller comes to mind, which I think uses the Freescale MPC500). I wonder how it works. If the opcodes can all be compressed, why not just make them smaller to begin with? I guess I always thought of opcodes as being enumerations of "commands".
  - wolf550e 10y ago
    RISC instructions are all the same size in bits to achieve fast decode speeds. Thus you must choose between 32bit instructions or 16bit instructions. ARM supports both, including function calls from one to the other.
    - plasticchris 10y ago
      This must have been solved, thumb 2 (https://en.wikipedia.org/wiki/ARM_architecture#Thumb-2 https://en.wikipedia.org/wiki/ARM_architecture#Thumb-2) mixes 16 and 32 bit instructions.