anon (no@reply.please) on 1/19/11 wrote:
---------------------------
>It's interesting to see all of the focus on backwards compatibility issues, and
>not so much on (in my opinion) one of the more fundamental issues with ARM: It's
>a fairly poor architecture as modern load-store designs go.
>
>I've done embedded system development on a range of ARM processors from ARM-7 through
>A9, as well as several Intel and Marvell designs. I've also worked extensively with
>MIPS, PowerPC, and ST-2xx in the embedded space as well as with x86 and a range
>of RISCs on the desktop. From an architectural cleanliness perspective ARM is second-worst of the lot, behind only x86.
>
>While it has plenty of flaws, ARM's single biggest challenge is that the instruction
>format fundamentally mis-allocates bits. It spends instruction bits on a half-baked
>condition-register-based predication scheme (which is somewhat vestigial in modern
>implementations with branch prediction and speculation) and a shift field, and consequently
>can only afford 16 GPRs. This makes ARM fairly unique among its RISC-ish peers,
>and not in a good way. I can't count the number of times I've pulled my hair out trying to manage spills/fills on ARM.
>
>I'd also remark that the ARM-designed microarchitectures were also amateurish up
>to and including ARM11. They didn't really figure out what they were doing on that
>front until R4/A8/A9 (which are at least competitive)

Your point of view seems pretty subjective and anecdotal. I've programmed a number of things for x86, ARM, and MIPS (ie, code that did the same thing for all platforms, not just separate code bases in general) and have benefited in tight inner loops from predication and folded shifting more than I would have from more registers. For instance rendering kernels that take half the number of instructions (and loosely, cycles) than they would on a comparable single-issue CPU. That's not to say I'm right and you're wrong, and it's certainly not to say that I wouldn't have ever benefited from more registers, but it really depends on what you're doing and you're not presenting a case of hard data. To me and many people I know ARM has been one of the nicest to code in, but that still says little about how good it actually is. Having to write assembly in something can actually be really bad for one's objective outlook on a CPU platform, and I'm sure that goes for both of us.

I would say predication is not rendered fully obsolete by (even very good) branch prediction, especially not in in-order or fairly narrow out of order processors. There are many useful cases where you just want to predicate one instruction and it's hard to match that with anything else. That said, I agree with you that it would have been nicer to use three of the bits on an extra GPR and just have one bit for predication and maybe a couple more ALU instructions for setting it in various ways, ie more SH-like.

So you say ARM-designed microarchitectures up to ARM11 are amateurish, but compared to what? The original ARM designs were very competitive with their contemporary the 386, offering much better IPC. From there the platform gradually moved into a direction of low-power embedded which obviously influenced its capabilities. Try comparing it again, but this time against mobile processors instead of ones targeting workstations. Or by analogy, maybe you should be dissing x86 for implementing OoOE some 30 years after it was invented. I hardly think ARM didn't know anything about CPU design when they did the successors to the original, they just consistently went with what the process/power constraints allowed.