Maybe, if they are able to work the security angle. Industrial embedded folk love to not know about security. Industrial equipment are also usually despised by IT folk. If Intel can give OEMs a standard dirt-simple to configure solution that electricians and HVAC techs can install without screwing up, they might have a horse to race.

>Presumably embedded systems security will be a bigger issue as we approach the future Internet of Things.)

Embedded systems security, or the lack of it, is a big issue now.

Every non-x86 processor from Intel has failed, so there's that.

8051 derivatives are still sold by the gazillions, if not by Intel.

Well, every non-x86-compatible processor anyway. And the article states that the Quark is x86-compatible.

The i960 did ok, and still finds use in some military applications. But, on the other hand, Itanic.

Let's not forget the iAPX 432, which failed far more spectacularly than Itanium. (Itanium even failed at failing, it seems).

Yep. Fond memories of writing an execution trace disassembler for the i960CA back in the early 90s. The chip had an 8-bit incremental trace bus, which made it possible to produce an execution-time instruction trace, as long as the code didn't modify the instructions in memory.

I wrote and instruction scheduler for the i960CA, which was fun. (For those who don't know, the i960CA was the first superscalar microprocessor.) It took assembly code as input and contained (as close as I could get from public docs to) a cycle accurate timing simulator.

Less fun was the associated project of getting the GNU assembler and linker to run under 16-bit DOS. I recall that at the the time the linker consisted of one giant source file, and one of the tools (I think the assembler) contained the wonderful declaration:

    int malloc();

4004