[转贴]ARM汇编中的常数8位位图

lenghuo2002

关注

转载最新推荐文章于 2020-04-14 12:05:41 发布 1.1k 阅读 AI 写同款· GEO 优化 ›

AI权益加码！Claude Code、Cursor等20+工具免费用！购周边限时加赠Coding Plan Lite，畅享主流AI工具！学习进阶更高效！阅读详情

关于ARM处理器中“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     第二个操作数

其指令编码格式如下：

31-28	27-25	24-21	20	19-16	15-12	11-0 （12位）
cond	001	opcode	S	Rn	Rd	shifter_operand

当第2 个操作数的形式为：＃immed_8r常数表达式时“该常数必须对应8位位图，即常数是由一个8位的常数循环移位偶数位得到的。 ”

其意思是这样：＃immed_8r在芯片处理时表示一个32位数，但是它是由一个8位数（比如：01011010，即0x5A）通过循环移位偶数位得到（1000 0000 0000 0000 0000 0000 0001 0110，就是0x5A通过循环右移2位（偶数位）的到的）。

而101 0 0000 0000 0000 0000 0000 0001 0110 ，就不符合这样的规定，编译时一定出错。因为你可能通过将1011 0101循环右移位得到它，但是不可能通过循环移位偶数位得到。

1011 0000 0000 0000 0000 0000 0001 0110 ，也不符合这样的规定，很明显：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位存移位的次数”，应该是最好的组合了（我并未想过所有的组合，只是顺便试了几个）。

原文链接http://blog.chinaunix.net/u1/34474/showart_355511.html