ARM mov instruction source constraints

[Crystal037]

Homework Statement

I am using immediate addressing to store a value in a register.
But I am getting an error: AI510E: Immediate 0x01010101 cant be represented by 0-255 and a rotation. My knowledge of ARM instruction lacks a bit.

Relevant Equations

MOV can store 32 bits as apparent from MOV r0,#0xFFFFFFFF
I don't know why is a number smaller than it is causing an error

 

[Mark44]

Your screen shot is too small for me to read your code. It's better to insert the text of the code surrounded by code tags than to post a screen shot that is unreadable. There's a sticky near the top of this forum section that talks about using code tags.

The following throwaway example shows how to move (copy) a 32-bit immediate value into a register. Another immediate value is moved to a second register, and the two values are added and placed into a third register. The sum is then displayed on the console.

I ran the code in the ArmSim simulator, software that was produced by several faculty members at the University of Victoria (BC) in Canada. The result displayed was the correct result.

    .eqv PRINT_INT, 0x6b
    .eqv TERMINATE, 0x11
    .eqv StdOut, 1

    .text
main:
    mov r0, #0x7FFFFFF0
    mov r1, #0xA
    add r2, r0, r1
    
    @Print the value
    mov r0, #StdOut
    mov r1, r2
    swi PRINT_INT

    swi #TERMINATE

 

[pbuk]

The error message tells you exactly why this won't work:

Immediate 0x01010101 can't be represented by 0-255 and a rotation.

There is no 32 bit MOV immediate instruction in ARM, there is an 8 bit MOV immediate followed by an even-number-of-bits rotation; there is also MVN which loads the complement. This leads to a restricted range of possible values explained in detail at https://developer.arm.com/documenta...nto-registers/Direct-loading-with-MOV-and-MVN

 

[Mark44]

There is no 32 bit MOV immediate instruction in ARM, there is an 8 bit MOV immediate followed by an even-number-of-bits rotation

Nevertheless, the code I showed earlier works. Perhaps that simulator is treating MOV with a 32-bit immediate as a pseudoinstruction. Another pseudoinstruction that I found right after the docs for MOV in the link you provided is MOV32, which does allow for 32-bit immediates (and which the assembler breaks up into a MOV and MOVT pair.

BTW, the MOV instruction on the linked-to page says it takes a 16-bit immediate, as in MOV r0, #0x1000.

 

[Crystal037]

Your screen shot is too small for me to read your code. It's better to insert the text of the code surrounded by code tags than to post a screen shot that is unreadable. There's a sticky near the top of this forum section that talks about using code tags.

The following throwaway example shows how to move (copy) a 32-bit immediate value into a register. Another immediate value is moved to a second register, and the two values are added and placed into a third register. The sum is then displayed on the console.

I ran the code in the ArmSim simulator, software that was produced by several faculty members at the University of Victoria (BC) in Canada. The result displayed was the correct result.

    .eqv PRINT_INT, 0x6b
    .eqv TERMINATE, 0x11
    .eqv StdOut, 1

    .text
main:
    mov r0, #0x7FFFFFF0
    mov r1, #0xA
    add r2, r0, r1
   
    @Print the value
    mov r0, #StdOut
    mov r1, r2
    swi PRINT_INT

    swi #TERMINATE

Sorry, but I can't find the section that talks about code tags can you give me a screen shot where am I supposed to go.
And the code I have implemented in keil microvision is as follows

    area rotate,code,readonly
entry
start 
    mov r4,#0x01010101
    mov r5,r4,ror #1
    end

And the error I am getting is
multiple-loadstore.asm(4): error: A1510E: Immediate 0x01010101 cannot be represented by 0-255 and a rotation

 

[Crystal037]

The error message tells you exactly why this won't work:

There is no 32 bit MOV immediate instruction in ARM, there is an 8 bit MOV immediate followed by an even-number-of-bits rotation; there is also MVN which loads the complement. This leads to a restricted range of possible values explained in detail at https://developer.arm.com/documenta...nto-registers/Direct-loading-with-MOV-and-MVN

About ARM having no 32-bit Mov instruction why am I not getting any error while using the constant 0xFFFFFFF1
Also can u explain me what do you mean by an even-number-of bits rotation.

 

[berkeman]

Sorry, but I can't find the section that talks about code tags can you give me a screen shot where am I supposed to go.

Here you go:

 

[pbuk]

Nevertheless, the code I showed earlier works.

That's because the value you have used is one of the permitted values.

Perhaps that simulator is treating MOV with a 32-bit immediate as a pseudoinstruction.

I don't know how that simulator works but as interpretation of possible 32 bit immediate MOVs is part of the ARM assembler specification I would expect the conversion from pseudoinstruction to be in the assembler layer rather than the simulation layer.

Another pseudoinstruction that I found right after the docs for MOV in the link you provided is MOV32, which does allow for 32-bit immediates (and which the assembler breaks up into a MOV and MOVT pair.

BTW, the MOV instruction on the linked-to page says it takes a 16-bit immediate, as in MOV r0, #0x1000.

Yes it does, this translates into a single 32 bit instruction containing the 16 bit immediate value. But if it is provided with a 32 bit immediate it will attempt to translate this into a single 32 bit instruction using an 8 bit immediate value and a 2k bit right rotation where k=0-15.

 

[pbuk]

About ARM having no 32-bit Mov instruction why am I not getting any error while using the constant 0xFFFFFFF1

Because that is one of the permitted values (it is the bitwise complement of 0x0000000E).

Also can u explain me what do you mean by an even-number-of bits rotation.

This is explained by the documentation I linked, for instance the value 0xFFF1FFFFF is a 32 bit rotation of 0xFFFFFFF1 and so permissible whereas 0xFFE3FFFF would be a 33 bit rotation* and so not permissible.

*If my mental binary-to-hex conversion is working properly.