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

Question

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

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 and my textbook, it's said that range of immediate number following MOV instruction is 0-255. But when I test on my own PC in ADS 1.2 IDE, instruction

MOV     R2, #0xFFFFFFFF

performs well. Isn't number 0xFFFFFFFF out of range according to the specification?

assembly

arm

cpu-architecture

machine-code

immediate-operand

asked on Stack Overflow Apr 12, 2010 by

Summer_More_More_Tea • edited Oct 28, 2020 by

Peter Cordes

7 Answers

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.

answered on Stack Overflow Apr 12, 2010 by

Michael Burr

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.

answered on Stack Overflow Apr 12, 2010 by

Matthew Slattery

MOV instruction can either accept imm16 value or Operator2 value (due to instruction length opposed to memory alignment), which must conform any of the following rules (copied from CortexM instruction set manual, X and Y is any hex-value):

Any constant that can be produced by shifting an 8-bit value left by any number of bits within a 32-bit word.
Any constant of the form 0x00XY00XY .
Any constant of the form 0xXY00XY00 .
Any constant of the form 0xXYXYXYXY .

This is why 0xFFFFFFFF is accepted (conforms 4th rule).

If you wish to assemble your own 32 bit constant, you can use instruction MOVT, which writes into the upper half of a register.

answered on Stack Overflow Nov 5, 2014 by

user4219605

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.

answered on Stack Overflow Nov 7, 2011 by

Jake 'Alquimista' LEE

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)?

answered on Stack Overflow Apr 12, 2010 by

dthorpe

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

answered on Stack Overflow May 31, 2019 by

Samuel Severance

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

answered on Stack Overflow Apr 12, 2010 by

Bill

User contributions licensed under CC BY-SA 3.0