Explanation of "8-Bit Bitmap, cyclic shift of even digits"

In the Assembly Language of the ARM processor, the constant expression of <shifter_operand> in the instruction syntax format stipulates: "This constant must correspond to an 8-Bit Bitmap, that is, constants are obtained from an even number of constant loops with eight bits."

Start with the syntax format of the arm command system.

The syntax format of an 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 form of # immed_8r constant expression, "the constant must correspond to an eight-Bit Bitmap, that is, the constant is obtained by an eight-bit constant cyclic shift of an even number ." It means this: # immed_8r represents a 32-digit number during chip processing, but it is stored by an 8-digit number (for example, 01011010, 0x5a) the result is obtained through cyclic shift of an even number of BITs (1000 0000 0000 0000 0000 0000 0001 0110, that is, 0x5a is shifted to 2 bits (even bits) Through cyclic shift ).

However, a 1010 0000 0000 0000 0000 0000 0001 0110 does not comply with such requirements and may cause errors during compilation. Because you may get the 1011 0101 loop by moving three places to the right, but it cannot be obtained by moving the even bits in the loop. Another 1011 0000 0000 0000 0000 0000 0001 0110 0110 does not comply with this rule. According to the shift rule, it is obtained from the first 1011 loop to the fourth place, but it is obvious: 1 0110 1011 has 9 digits and does not match.

Why is there such a rule?

A big brother understands that:

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 stored data: explains that "this constant must correspond to 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. I also want to think about the "8-bit data storage, 4-Bit Data Storage shift times", which should be the best combination (I didn't think about all the combinations, but I tried a few by the way ). So the even bits (, 4,... 28, 30) are shifted cyclically, and only loops to the right can be performed.

Bytes ------------------------------------------------------------------------------------------------------------------------

 

With the above explanation, the following examples are clear:

 

Command ①: And R1, R2, # 0xff
When the processor processes the second operand 0xff of this instruction, because 0xff is an 8-bit binary number, the processor directly puts it into the 8-bit "Basic" number, the four-digit "shift" value is 0.
Command ②: And R1, R2, #0x104
When the processor processes the second operand 0x104 of this instruction, because 0x104 has exceeded the 8-bit binary number, the processor needs to "modify" it, first, convert 0x104 to binary 0000 0000 0000 0000 0000 0001 0000 0100 0000 0000. We can see that this number is 0000 0000 0000 0000 0100 0001 obtained by moving 30 bits to the right through a loop, therefore, the result after transformation is that the 8-bit "Basic" number is 0100, and the "shift" number is 15.
Command ③: And R1, R2, #0xff000000
When the processor processes the second operand 0xff000000 of this instruction, the processor also needs to "modify" it. First, convert 0xff000000 to binary 1111 1111 0000 0000 0000 0000 0000. We can see that, this number is 0000 0000 0000 0000 0000 0000 1111 1111 obtained by moving the right eight digits of the loop. Therefore, after transformation, the result is that the 8-digit "Basic" number is 1111, the number of "shifts" is 4.

I think, through the above three examples, we should understand the principle of the 8-Bit Bitmap. However, some numbers do not conform to the principle of an 8-Bit Bitmap. During program compilation, the system will prompt an error.

Here are some examples of Bitmap violations:

For example, if 0x101 is converted to a binary value of 0000 0000 0000 0000 0000 0001 0000 0001, no matter how many bits the number is round to the right, the two 1 s cannot be placed in the Lower 8 bits at the same time, therefore, the bitmap does not conform to the 8-Bit Bitmap. For example, if 0x102 is used, the bitmap is converted to the binary 0000 0000 0000 0000 0000 0001 0000 0010. If two 1 bits are placed in the Lower 8 bits, that is to say, after the binary value is converted to 0000 0000 0000 0000 0000 0000 1000 0001, the binary number needs to be shifted to 31 places on the right, which does not meet the condition for moving the even digits to the right of the loop, therefore, 0x012 does not conform to the 8-Bit Bitmap. After converting 0xff1 to a binary value, there will be 9 1, which cannot be put into the 8-Bit Bitmap at the same time.
The comparison between positive and negative examples can be summarized as follows:

First, determine whether a number conforms to the principle of 8-Bit Bitmap:

I. First, check whether the number of 1 after this number is converted to binary cannot exceed 8

II. If there are no more than 8 values, check whether the N 1 (n <= 8) values can be put in 8 binary digits at the same time.

(The above two can be determined by judging the distance between the upper and lower bound 1 <7)

Iii. If it can be put in, check whether the eight binary bits can be cyclically shifted to the even bits to obtain the value initially determined. If yes, this value is in line with the 8-Bit Bitmap principle. Otherwise, it does not.

Second, it is impossible to use 12-bit encoding to represent an arbitrary 32-bit number. You can only obtain part Of the 32-bit number by looping the eight-bit binary number to an even number, the remaining 32 digits that cannot be expressed can only be obtained through other means, such as 0xffffff00, which can be obtained through the bitwise inversion of 0x000000ff.

** In future programming, you must pay attention to whether the second operand conforms to an 8-Bit Bitmap.