In principle, graphics is different - they have to do graphics development given their need for integrated graphics, and they have an established (if quite rocky) history of highly parallel HPC accelerators/processors.

Cell modem development was always something of an odd fit for Intel - it came in from an acquisition, and due to the complexities of patents and Qualcomm's domination of the modem market they only had one major customer (Apple) who used them primarily as legal leverage. Once that customer went away, it became unsustainable given the high R&D costs combined with questionable demand for discrete modems.

Intel's flirtation with low-end embedded devices makes sense on the basis that they already were using low-power Pentium-derived cores as embedded controllers, so why not offer them as standalone products. I think they clearly underestimated the costs of packaging and support for external customers, as well as the dominance ARM's Cortex-M series would establish.

They did also used to actually make ARM processors. Originally they acquired StrongARM from Digital, and then went on to replace the brand with their own XScale, and found some pretty good success in embedded systems and were at one point near-universal in PDAs and high-end mobiles (a huge customer at the time was RIM who put them in all of their Blackberries at one point). They sold that off though and it fell behind, but they actually still hold DEC's ARM license.

So they did have some prior experience in that space, but that experience was built on the shoulders of what Digital was doing.

I don't think it was a lack of experience with what ARM designs could do. If I were to guess, their hope was that a nominally-familiar architecture would make porting easier for customers interested in building low-end embedded + server/cloud products from the same codebase; i.e. both your embedded client devices and servers would use the same libraries IPC/encryption/etc (same idea that node lets you reuse code between client and server).

Of course the stumbling block there is that the Cortex-M family (rather than 8051, AVR, and PIC generations before) was already designed around good C/C++ support, and the server->embedded code reuse jump is bigger than the work involved in switching architectures. And, of course, the Cortex-M vendors already had lots of experience producing all the microcontroller variants with the particular peripherals their customers want, which is just as, if not more important than the architecture.

Certainly, I wasn't trying to suggest that, and was more just raising the point that they did once have a competitive embedded line, but sold it and then came back to the market down the road with a much weaker approach.

> they actually still hold DEC's ARM license.

Does that give them modern ARM processors or just the ones of the time?

It's an ISA licence, so they're allowed to design their own processors that implement ARM, but they would have to design them themselves (which is why they haven't)

Actually, through their Altera acquisition, they must have design licenses for a number of recent Cortex-A variants as well, since a number of their FPGAs have ARM cores.