Understanding of "8-Bit Bitmap" in arm Processors

In the Assembly Language of the ARM processor, the constant expression of <shifter_operand> in the instruction syntax format is as follows:"The constant must correspond to an 8-Bit Bitmap, that is, the constant is obtained by an 8-bit constant cyclic shift of an even number ".

Start with the syntax format of the arm command system.

The syntax format of a typical arm command is divided into the following parts:
<Opcode >{< cond >}{ s} <RD >,< rn >{, <shifter_operand>}
Items in <> are mandatory, and items in {} are optional. For example, <opcode> is a command enable and required, {<cond>} is an optional command execution condition. If no value is specified, the default condition Al (unconditional execution) is used ).
Opcode command mnemonic, such as LDR and Str
Cond execution conditions, such as EQ and ne
Whether s affects the value of the CPSR register. CPSR is affected when writing; otherwise, no effect is imposed.
Rd target register
Register of the first operand OF Rn
Shifter_operand second operand

 

The instruction encoding format is as follows:

31-28	27-25	24-21	20	19-16	15-12	11-0 (12 digits)
Cond	001	Opcode	S	Rn	Rd	Shifter_operand

 

When the first operand is in the format of # immed_8r constant expression,"The constant must correspond to an 8-Bit Bitmap, that is, the constant is obtained by an 8-bit constant cyclic shift of an even number."

It means this: # immed_8r represents a 32-digit number during chip processing, but it consists of an 8-digit number (for example, 01011010, that is, 0x5a) after the even bits of the cyclic shift are obtained (1000 0000 0000 0000 0000 0000 0001 0110, that is, 0x5a shifts two bits to the right through the cyclic shift (Even number).

While 1010 0000 0000 0000 0000 0000 0001 0110 does not comply with such regulations, and errors may occur during compilation. Because you may get it by right shifting the 1011 0101 loop, but it is impossible to get it through circular shiftEven number.

1011 0000 0000 0000 0000 0000 0001 does not comply with such regulations, obviously: 1 0110 0110 has 9 digits.

Why is there such a rule?

My understanding is:

Explain from the instruction encoding format (this is why I first talked about the instruction encoding format), and carefully check the number of digits occupied by shifter_operand In the table: 12 digits. It is absolutely impossible to use a 12-bit code to indicate any 32-bit number (12-bit numbers may be 2 ^ 12, and 32-bit numbers may be 2 ^ 32 ).

But we need to use 12-bit encoding to represent 32 digits. What should we do?

Only limit the number. 12-bit encoding is used to represent 32 digits.

In 12-bit shifter_operand: 8-bit stored data, 4-bit stored shift times.

8-Bit Data Storage: explains"The constant must correspond to an 8-Bit Bitmap.".

The number of 4-Bit Memory shifts: explains why only even digits can be moved. There are only 16 possible values for four bits, and 32 bits can be shifted cyclically for 32 times (32 possibilities), so we have to limit that only the even bits can be moved (two bits, it seems that a 16-digit shift is possible ). In this way, the contradiction that can be expressed is half of the actual situation.

Therefore, the limit on the # immed_8r constant expression is to solve the problem that the second number of operands in instruction encoding is not enough to indicate the helplessness of 32-bit operands, but in my opinion, this can be said to be a smart approach. Because if a 32-bit operand is expressed by 12 digits, it can only represent 0 to (2 ^ 12-1 ). A value greater than (2 ^ 12-1) cannot be expressed. In addition, I want to carefully consider "8-bit data storage, 4-Bit Data Storage shift times"

 

 

 

Let's use a few immediate numbers to calculate it again.

A) 0x00ab0000 means 0000 0000 1010 1011 0000. We can check that the interval between the first "1" and the last "1" in this number is 8, satisfying the 8-Bit Bitmap idea. 0xc000002a can be obtained by moving 22 Bits to the right of the loop 0x00ab0000.

B) 0x00001f80 is 0000 0000 0000 0000 0001 1111 1000 0000 this number also satisfies the 8-Bit Bitmap idea. 0xfe obtains this number by moving the even bits cyclically.

C) 0x0000ffff the first "1" and the last "1" exceeds 8 bits, so this number is an invalid immediate number.

D) 0xf000000f this number is a valid immediate number. Maybe we may have some doubts, because the first "1" and the last "1" have exceeded 8 digits, 0xf000000f can be operated through cyclic shift. We can shift F to the right to get 0xff000000, and this function can also be obtained by moving the even bits cyclically, therefore, this number is also a valid number that satisfies the 8-Bit Bitmap.

E) 0 xffffffff, which is an invalid number immediately. This function does not meet the 8-Bit Bitmap operation, but can still be used during compilation

MoV r0, #0 xffffffff
The final compilation result should be MVN R2, #0, that is, return 0 to R2.