[callan]

Disclaimer: I'm a software guy @ Intel.

I feel that a lot of sw folks have a lack of imagination when it comes to hw. A lot of very smart people here work on making an efficient, fast front-end. There's lots of research in this area. To my eyes, the implementations are stunning.

To say that a variable-length CISC instruction set can never be as fast or effecient as ARM is sort-of like saying that an interpreted language can never be as fast as C. And we all know how that goes over on HN.

[Symmetry]

I'm sure the front end has had a lot of work and cleverness put into it, and I'm sure that it's able to, say, correctly guess where instruction boundaries are more than 99% of the time without knowing for sure and then remove those instructions from the queue if it turns out that the guess was wrong. But that just means that 4-wide decode is only on the same order of power consumption as execution, instead of being an order of magnitude more like if you'd done thing the naive way. I'm sure that the work they do _is_ stunning, but its work that doesn't even have to be done on more regular instruction sets.

It's not a problem with being variable length or CISC, its a problem with the lack of self-synchronization. If you, say, had 8 or 16 bit blocks were first bit of each block told you whether it was the beginning of an instruction you wouldn't have this problem at all. I'd generally say that for a modern general purpose computer variable length instructions and a large number of op-codes are a good idea, though a large number of addressing modes seems to still be a disadvantage. Its probably no accident that ARM, the "CISCiest" of the RISC processors is so popular right now.

[phamilton]

But don't ARM/Marvell/Qualcomm/Nvidia have a lot of smart people working on making an efficient fast front-end?

Overcoming an obstacle is great, but I feel like companies who don't have to overcome that obstacle can focus their energy on other aspects of the product.