关于 “8位位图、循环移位偶数位” 的解释（转）
转自http://www.cnblogs.com/yin-jingyu/archive/2011/10/16/2214032.html
在ARM处理器的汇编语言中，对指令语法格式中的<shifter_operand>的常数表达式有这样的规定：“该常数必须对应8位位图，即常数是由一个8位的常数循环移位偶数位得到的。”
首先从ARM指令系统的语法格式说起。
一条ARM指令语法格式分为如下几个部分：
<opcode>{<cond>}{S} <Rd>,<Rn>{,<shifter_operand>}
其中，<>内的项是必须的，{}内的项是可选的，如<opcode>是指令助记符，是必须的，而{<cond>}为指令执行条件，是可选的，如果不写则使用默认条件AL(无条件执行)。
Opcode 指令助记符，如LDR，STR 等
Cond 执行条件，如EQ，NE 等
S 是否影响CPSR 寄存器的值，书写时影响CPSR，否则不影响
Rd 目标寄存器
Rn 第一个操作数的寄存器
shifter_operand 第二个操作数
其指令编码格式如下：
当第2 个操作数的形式为：＃immed_8r常数表达式时“该常数必须对应8位位图，即常数是由一个8位的常数循环移位偶数位得到的。”其意思是这样：＃immed_8r在芯片处理时表示一个32位数，但是它存储的时候是由一个8位数（比如：01011010，即0x5A）通过循环移位偶数位得到（1000 0000 0000 0000 0000 0000 0001 0110，就是0x5A通过循环右移2位（偶数位）的到的）。
但是一个1010 0000 0000 0000 0000 0000 0001 0110，就不符合这样的规定，编译时一定出错。因为你可能通过将1011 0101循环右移3位得到它，但是不可能通过循环移位偶数位得到。另一个1011 0000 0000 0000 0000 0000 0001 0110，也不符合这样的规定，按移位算是由1 0110 1011循环右移4位得到它，但是很明显：1 0110 1011 有9位，不符合。
为什么要有这样的规定？
有位大哥的理解是：
要从指令编码格式来解释（这就是我为什么一开始讲的是指令编码格式），仔细看表格中的shifter_operand所占的位数：12位。要用一个12位的编码来表示任意的32位数是绝对不可能的（12位数有2^12种可能，而32位数有2^32种）。但是又要用12位的编码来表示32位数，怎么办？ ？？？
只有在表示数的数量上做限制。通过编码来实现用12位的编码来表示32位数。
在12位的shifter_operand中：8位存数据，4位存移位的次数。8位存数据：解释了“该常数必须对应8位位图”。
4位存移位的次数：解释了为什么只能移偶数位。4位只有16种可能值，而32位数可以循环移位32次（32种可能），那就只好限制：只能移偶数位（两位两位地移，好像一个16位数在移位，16种移位可能）。这样就解决了能表示的情况是实际情况一半的矛盾。
所以对＃immed_8r常数表达式的限制是解决指令编码的第二个操作数位数不足以表示32位操作数的无奈之举，但在我看来：这个可以说是聪明的做法。因为如果直接用12位数来表示32位操作数，只能表示0 到（2^12-1）。大于(2^12-1)的数就没办法表示了。而且细细想来“8位存数据，4位存移位的次数”，应该是最好的组合了（我并未想过所有的组合，只是顺便试了几个）。所以被循环移位偶数位(0,2,4,...28,30)，并且只能向右循环。
------------------------------------------------------------------------------------------------------------------------
有了上述解释，接下来举例说明就很清楚了：
指令①： AND R1,R2,#0xff
当处理器处理这条指令的第二操作数0xff时，因为0xff为8位二进制数，所以处理器就将其直接放进8位“基本”数中，而4位“移位”数则为0.
指令②： AND R1,R2,#0x104
当处理器处理这条指令的第二操作数0x104时，因为此时0x104已经超过了8位二进制数，所以处理器就要将其“改造”一下，我们先把0x104转换成二进制0000 0000 0000 0000 0000 0001 0000 0100,我们可以看到，这个数是0000 0000 0000 0000 0000 0000 0100 0001通过循环右移30位得到的，因此改造后的结果是8位“基本”数中存放0100 0001，而“移位”数为15。
指令③： AND R1,R2,#0xff000000
当处理器处理这条指令的第二操作数0xff000000时，处理器同样要对其“改造”，我们先把0xff000000转换成二进制1111 1111 0000 0000 0000 0000 0000 0000,我们可以看到，这个数是0000 0000 0000 0000 0000 0000 1111 1111通过循环右移8位得到的，因此改造后的结果是8位“基本”数中存放1111 1111，而“移位”数为4。
我想，通过以上的三个例子，就应该明白了8位位图的原理了。但是，有些数并不符合8位位图的原理，这样的数在进行程序编译时，系统将会提示出错 。
下面再举几个违反8位位图的例子：
比如0x101，转换成二进制后位0000 0000 0000 0000 0000 0001 0000 0001，像这个数，无论向右循环几位，都无法将两个1同时放到低8位中，因此不符合8位位图；再比如0x102，转换成二进制后位0000 0000 0000 0000 0000 0001 0000 0010，如果将两个1同时放到低8位中，即转换成二进制后为0000 0000 0000 0000 0000 0000 1000 0001，需要将此二进制数向右移31位，这也不符合循环右移偶数位的条件，因此0x012也不符合8位位图；再举一个0xff1，转换成二进制后将会有9个1，不可能将其同时放入8位中，因此当然也不符合啦。
通过正反例的比较，可以总结如下：
第一，判断一个数是否符合8位位图的原则：
i、首先看这个数转换成二进制后1的个数是否不超过8个
ii、如果不超过8个，再看这n个1（n<=8）是否能同时放到8个二进制位中
（上面这两条 可以通过 判断 上界 1 和 和下界 1之间的距离 < 7 来判断）
iii、如果可以放进去，再看这八个二进制位是否可以循环右移偶数位得到起初被判断的那个数值，如果可以，则此数值即为符合8位位图原理，否则，不符合。
第二，用12位的编码来表示一个任意的32位数是不可能的，只能通过循环右移八位二进制数偶数位来得到一部分32位数，其余的无法表示的32位数，只有通过其它途径获得了，比如0xffffff00，可以通过0x000000ff按位取反得到.
** 因此在以后的编程中，一定要注意用到的第二操作数是否符合8位位图。
在ARM处理器的汇编语言中，对指令语法格式中的<shifter_operand>的常数表达式有这样的规定：“该常数必须对应8位位图，即常数是由一个8位的常数循环移位偶数位得到的。”
首先从ARM指令系统的语法格式说起。
一条ARM指令语法格式分为如下几个部分：
<opcode>{<cond>}{S} <Rd>,<Rn>{,<shifter_operand>}
其中，<>内的项是必须的，{}内的项是可选的，如<opcode>是指令助记符，是必须的，而{<cond>}为指令执行条件，是可选的，如果不写则使用默认条件AL(无条件执行)。
Opcode 指令助记符，如LDR，STR 等
Cond 执行条件，如EQ，NE 等
S 是否影响CPSR 寄存器的值，书写时影响CPSR，否则不影响
Rd 目标寄存器
Rn 第一个操作数的寄存器
shifter_operand 第二个操作数
其指令编码格式如下：
 |
当第2 个操作数的形式为：＃immed_8r常数表达式时“该常数必须对应8位位图，即常数是由一个8位的常数循环移位偶数位得到的。”其意思是这样：＃immed_8r在芯片处理时表示一个32位数，但是它存储的时候是由一个8位数（比如：01011010，即0x5A）通过循环移位偶数位得到（1000 0000 0000 0000 0000 0000 0001 0110，就是0x5A通过循环右移2位（偶数位）的到的）。
但是一个1010 0000 0000 0000 0000 0000 0001 0110，就不符合这样的规定，编译时一定出错。因为你可能通过将1011 0101循环右移3位得到它，但是不可能通过循环移位偶数位得到。另一个1011 0000 0000 0000 0000 0000 0001 0110，也不符合这样的规定，按移位算是由1 0110 1011循环右移4位得到它，但是很明显：1 0110 1011 有9位，不符合。
为什么要有这样的规定？
有位大哥的理解是：
要从指令编码格式来解释（这就是我为什么一开始讲的是指令编码格式），仔细看表格中的shifter_operand所占的位数：12位。要用一个12位的编码来表示任意的32位数是绝对不可能的（12位数有2^12种可能，而32位数有2^32种）。但是又要用12位的编码来表示32位数，怎么办？ ？？？
只有在表示数的数量上做限制。通过编码来实现用12位的编码来表示32位数。
在12位的shifter_operand中：8位存数据，4位存移位的次数。8位存数据：解释了“该常数必须对应8位位图”。
4位存移位的次数：解释了为什么只能移偶数位。4位只有16种可能值，而32位数可以循环移位32次（32种可能），那就只好限制：只能移偶数位（两位两位地移，好像一个16位数在移位，16种移位可能）。这样就解决了能表示的情况是实际情况一半的矛盾。
所以对＃immed_8r常数表达式的限制是解决指令编码的第二个操作数位数不足以表示32位操作数的无奈之举，但在我看来：这个可以说是聪明的做法。因为如果直接用12位数来表示32位操作数，只能表示0 到（2^12-1）。大于(2^12-1)的数就没办法表示了。而且细细想来“8位存数据，4位存移位的次数”，应该是最好的组合了（我并未想过所有的组合，只是顺便试了几个）。所以被循环移位偶数位(0,2,4,...28,30)，并且只能向右循环。
------------------------------------------------------------------------------------------------------------------------
有了上述解释，接下来举例说明就很清楚了：
指令①： AND R1,R2,#0xff
当处理器处理这条指令的第二操作数0xff时，因为0xff为8位二进制数，所以处理器就将其直接放进8位“基本”数中，而4位“移位”数则为0.
指令②： AND R1,R2,#0x104
当处理器处理这条指令的第二操作数0x104时，因为此时0x104已经超过了8位二进制数，所以处理器就要将其“改造”一下，我们先把0x104转换成二进制0000 0000 0000 0000 0000 0001 0000 0100,我们可以看到，这个数是0000 0000 0000 0000 0000 0000 0100 0001通过循环右移30位得到的，因此改造后的结果是8位“基本”数中存放0100 0001，而“移位”数为15。
指令③： AND R1,R2,#0xff000000
当处理器处理这条指令的第二操作数0xff000000时，处理器同样要对其“改造”，我们先把0xff000000转换成二进制1111 1111 0000 0000 0000 0000 0000 0000,我们可以看到，这个数是0000 0000 0000 0000 0000 0000 1111 1111通过循环右移8位得到的，因此改造后的结果是8位“基本”数中存放1111 1111，而“移位”数为4。
我想，通过以上的三个例子，就应该明白了8位位图的原理了。但是，有些数并不符合8位位图的原理，这样的数在进行程序编译时，系统将会提示出错 。
下面再举几个违反8位位图的例子：
比如0x101，转换成二进制后位0000 0000 0000 0000 0000 0001 0000 0001，像这个数，无论向右循环几位，都无法将两个1同时放到低8位中，因此不符合8位位图；再比如0x102，转换成二进制后位0000 0000 0000 0000 0000 0001 0000 0010，如果将两个1同时放到低8位中，即转换成二进制后为0000 0000 0000 0000 0000 0000 1000 0001，需要将此二进制数向右移31位，这也不符合循环右移偶数位的条件，因此0x012也不符合8位位图；再举一个0xff1，转换成二进制后将会有9个1，不可能将其同时放入8位中，因此当然也不符合啦。
通过正反例的比较，可以总结如下：
第一，判断一个数是否符合8位位图的原则：
i、首先看这个数转换成二进制后1的个数是否不超过8个
ii、如果不超过8个，再看这n个1（n<=8）是否能同时放到8个二进制位中
（上面这两条 可以通过 判断 上界 1 和 和下界 1之间的距离 < 7 来判断）
iii、如果可以放进去，再看这八个二进制位是否可以循环右移偶数位得到起初被判断的那个数值，如果可以，则此数值即为符合8位位图原理，否则，不符合。
第二，用12位的编码来表示一个任意的32位数是不可能的，只能通过循环右移八位二进制数偶数位来得到一部分32位数，其余的无法表示的32位数，只有通过其它途径获得了，比如0xffffff00，可以通过0x000000ff按位取反得到.
** 因此在以后的编程中，一定要注意用到的第二操作数是否符合8位位图。
