How can ARM's MOV instruction work with a large number as the second operand?

Question

I just begin to study ARM assembly language, and am not clear about how to use MOV to transfer an immediate number into a register.

From both the ARM reference manual

Answer 1

Remember that the ARM can perform a certain set of manipulations on the immediate value as part of the barrel shifter that is incorporated into the ARM's opcodes.

This little article has one of the clearest explanations of some of the tricks that an ARM assembler can use to fit a large immediate number into the small available space of an ARM instruction:

• http://www.davespace.co.uk/arm/introduction-to-arm/immediates.html

The article discusses the trick likely used in your specific example of generating a MVN opcode to load the bitwise complement of the immediate value.

These kinds of manipulation can't be done with all immediate values, but the ARM assemblers are supposedly pretty smart about it (and C compilers certainly are). If no shift/complement tricks can be performed, the value will generally be loaded from a PC-relative location or maybe by 'building up' the value from several instructions.

Answer 2

A single ARM instruction can only encode an immediate constant that can be represented as an 8-bit immediate value, shifted by any even power of two.

However, there is also a MVN instruction, which is like MOV but inverts all the bits. So, while MOV R2, #0xFFFFFFFF cannot be encoded as a MOV instruction, it can be encoded as MVN R2, #0. The assembler may well perform this conversion for you.

Answer 3

You may be seeing artifacts from sign-extension of the original value. If the tools you're using to view the disassembly handles the 0..255 as a signed byte, then when it loads it into a larger int type (or register) it will fill all the upper bits with the sign bit of the original value. Or to put it another way, if 0xFF is a signed byte its decimal value is -1. Put that into a 32 bit register and the hex will look like 0xFFFFFFFF, and its decimal value is still -1.

Try using a value without the high bit set, such as 0x7F. Since the sign bit is not set, I'm guessing it will fill the upper bits with zero when loaded into a larger int type register or field.

It's also possible that the compiler/assembler truncates whatever value you provide. I'd consider it a source code error, but assemblers are funny beasts. If you give it 0x7FF, does it compile to 0x7FF (not truncated, and larger than 0..255) or to 0xFFFFFFFF (truncated to 0..255, signed byte)?

Answer 4

If you want to move 0xffffffff to a register you can always do:

MOV R0, #-1

because 0xffffffff is the twos-complement representation of -1

Answer 5

It's somewhat hard to determine if the given constants are within the valid range.

Like Matthew already mentioned, the assembler lends you hand by replacing given instructions with similar, negating ones, like mov/mvn, cmp/cmn, tst/tne etc.

Answer 6

One possibility is that the ARM assembler throws away the significant bits of the number and uses only the lowest FF.

The MOV instruction is a staple in many CPU instruction sets, and usually the assembler resolves the size of the target register and the immediate value being supplied.

For example the following MOV instructions from the x86 set are

MOV BL, 80h, ; 8bit
MOV BX, ACACh ;16bit
MOV EBX, 12123434h ; 32bit