Understanding of 8-bit bitmap when the second operand in ARM instructions is a constant expression

   {} {S}      ,{,}
   Among them, the items in <> are required, and the items in {} are optional. For example, is the instruction mnemonic, which is required, and {} is the instruction execution condition, which is optional. If it is not written, the default condition AL (unconditional execution) is used.
   opcode       instruction mnemonic, such as LDR, STR, etc.
   cond         execution condition, such as EQ, NE, etc.
   S            whether to affect the value of the CPSR register, if written, it affects the CPSR, otherwise it does not affect
   Rd           target register
   Rn           register of the first operand
  operand2     second operand

  The instruction encoding format is as follows:

The constant expression of operand2 has the following stipulation: "The constant must correspond to an 8-bit bitmap, that is, the constant is obtained by rotating an 8-bit constant right by an even number of bits." This sentence means that when a 12-bit second operand is used to represent a 32-bit immediate number, the 8-bit number is implemented by shifting, where the lower eight bits of the 12-bit second operand store the "basic" number to be shifted (the value range is 0 to 255), and the upper four bits store the number of bits to be rotated right, because It is a four-bit binary number, so the value range is 0 to 15, and the corresponding shift number is 0 to 30. That is to say, if the "shift" number is 0, it means that the "basic" number remains unchanged. If the "shift" digit is 1, it means that the "basic" number is shifted right by 2 bits in the 32-bit digital space. If the "shift" digit is 5, it means that the "basic" number is shifted right by 10 bits in the 32-bit digital space. If the "shift" digit is 10, it means that the "basic" number is shifted right by 20 bits in the 32-bit digital space, and so on. For example:
     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 puts it directly into the 8-bit "base" number, and the 4-bit "shift" number is 0.
     AND  R1,R2,#0x104
     When the processor processes the second operand 0x104 of this instruction, because 0x104 has exceeded the 8-bit binary number at this time, the processor has to "transform" it. We first convert 0x104 into binary 0000 0000 0000 0000 0000 0001 0000 0100, we can see that this number is 0000 0000 0000 0000 0000 0000 0100 0001 obtained by circularly shifting right 30 bits. Therefore, the result of the transformation is 0100 stored in the 8-bit "base" number. 0001, and the "shift" number is 15.
     AND  R1, R2, #0xff000000
     When the processor processes the second operand 0xff000000 of this instruction, the processor also needs to "transform" it. We first convert 0xff000000 into binary 1111 1111 0000 0000 0000 0000 0000 0000 0000. We can see that this number is 0000 0000 0000 0000 0000 0000 1111 1111 obtained by circular right shifting 8 bits. Therefore, the result after transformation is 1111 1111 stored in the 8-bit "basic" number, and the "shift" number is 4.
      I think, through the above three examples, we should understand the principle of 8-bit bitmap. However, some numbers do not conform to the principle of 8-bit bitmap. When compiling a program, the system will prompt an error for such numbers. Here are a few examples that violate the 8-bit bitmap: for example, 0x101, converted to binary, is 0000 0000 0000 0000 0000 0001 0000 0001. For a number like this, no matter how many bits to the right you rotate, you cannot put two 1s in the lower 8 bits at the same time, so it does not conform to the 8-bit bitmap. Another example is 0x102, converted to binary, is 0000 0000 0000 0000 0000 0001 0000 0010. If two 1s are put in the lower 8 bits at the same time, the binary number is 0000 0000 0000 0000 0000 0000 1000 0001, this binary number needs to be shifted 31 bits to the right, which does not meet the condition of cyclic right shift of even bits, so 0x012 does not meet the 8-bit bitmap either; another example is 0xff1, which will have 9 1s after being converted into binary, and it is impossible to put them into 8 bits at the same time, so of course it does not meet the requirement.
      By comparing the positive and negative examples, we can summarize as follows: First, to determine whether a number meets the principle of 8-bit bitmap, first check whether the number of 1s does not exceed 8 after the number is converted into binary. If not, check whether these n 1s (n<=8) can be put into 8 binary bits at the same time. If they can be put in, check whether these eight binary bits can be cyclically right shifted by even bits to get the value initially judged. If so, this value meets the principle of 8-bit bitmap, otherwise, it does not meet the requirement. Second, it is impossible to represent an arbitrary 32-bit number using a 12-bit code. Only part of the 32-bit number can be obtained by cyclically right-shifting the even bits of the eight-bit binary number. The remaining 32-bit numbers that cannot be represented can only be obtained through other means. For example, 0xffffff00 can be obtained by bitwise inversion of 0x000000ff. Therefore, in future programming, you must pay attention to whether the second operand used conforms to the 8-bit bitmap.