why unsigned types are more efficent in arm cpu?

Question

I'm reading an arm manual and come to this suggestion, but the reason is not mentioned.

Why unsigned types are faster?

Answer 1

This question's answers might help you.

Answer 2

I think it's just that the instruction set for ARM CPUs is optimized for unsigned. Some operations can be done with one instruction for unsigned types but will need multiple instructions if it's signed. That's why I think if compiling for ARM in most (all?) C and C++ compilers it defaults to unsigned char rather than the more usual signed char.

Answer 3

The only advantages of unsigned types I can think of are that division and modulo implementations may be slightly faster, and you can do tests like if (unsigned_value < limit) rather than if (signed_value >= 0 && signed_value < limit).

I suspect your manual may be out of date. Any ARM in use today will have v4 or later of the instruction set, and I'm pretty sure that no instructions are faster or slower depending on signedness.

On older ARMs, I believe that signed multiplication could be slower; I think that early termination only looked for all zeros in the top bits, not all ones, so multiplications involving negative numbers would always take the maximum time. Although this depended on the value, not on whether the type was signed or unsigned. On at least ARMv4 and later, early termination works for negative values.

Also, I think very early ARMs couldn't load a single byte, only a word. So you'd need two instructions to load an unsigned byte, and three to load a signed one:

ldr r0, [r1]
and r0, r0, #0xff

versus

ldr r0, [r1]
mov r0, r0, asl #24
mov r0, r0, asr #24   ; but this could maybe be combined with later instructions

versus (these days) ldrb r0, [r1] or ldrsb r0, [r1] to do a single-byte load.

On a modern processor, it's very unlikely that using unsigned types will have a measurable impact on performance. Use whichever type makes most sense, then look at the code in detail once you've identified any performance bottlenecks.