ARM汇编和x86汇编的区别

35

我现在要学习 ARM 汇编语言,以便为我的 Windows Mobile 5 iPAQ 开发,但我有一些问题:

  • ARM 汇编语言和 x86 汇编语言的主要区别是什么?
    • 在中断方面是否有任何不同(新类型)?
      • 它们是什么,它们的含义是什么?
    • 最好的汇编器在哪里获取?
  • 我可以在哪里找到一些好的资源?

32
ARM汇编语言容易为人理解。x86汇编语言则是一堆历史遗留问题,错综复杂的非笛卡尔式走廊和神秘的扩展指令,只有编译器能够处理! - bobince
7
如果人类能够理解ARM,那么我的狗肯定可以编写MIPS程序! - new123456
https://dev59.com/lGUq5IYBdhLWcg3wF8nw#14795541 - auselen
2个回答

58

主要区别:

  • ARM是一种RISC风格的架构 - 指令具有固定大小(标准ARM为32位,Thumb模式为16位,尽管Thumb有一些指令会占用2个指令“插槽”)

  • 至少到ARM v5架构(我不确定v6做了什么),ARM上的中断模型与英特尔大相径庭 - 它不是将寄存器推入堆栈,而是切换到另一个集合的寄存器,这些寄存器“影子”正常的寄存器。处理器的模式决定了哪个寄存器文件可见(并非所有寄存器都一定被遮蔽)。这是一个相当复杂的安排。较新的ARM架构(至少在v7上)具有更接近英特尔的中断模型,在中断发生时将寄存器推入堆栈。

Arm指令具有一些有趣的特性,Intel没有:

  • 指令内置条件标志 - 因此,如果指定的条件标志与当前状态寄存器标志状态不匹配,则每条指令可以执行为NOP(在Intel汇编中经常看到跳过一两个指令的跳转)。
  • ARM具有可以嵌入指令的移位逻辑。因此,在使用寄存器作为源操作数时,您可以将其作为指令的内在部分进行移位。这有助于对数组进行索引,有时还有助于进行算术运算。

另一方面,ARM除了从内存中加载和存储之外,不能直接执行更多内存操作。Intel汇编可以直接在内存上执行更多操作。

请注意,ARM架构版本与实际ARM处理器版本并不直接对应 - 例如,如果我没记错,ARM7是一个架构v5处理器。个人认为,这比它应该的要更令人困惑。

可以从http://www.arm.com免费下载ARM架构参考资料。我还建议获取Hitex各种ARM微控制器指南,作为一个很好的起点。

关于入门 ARM 的指针有几个 Stackoverflow 问题。回顾它们将为你提供很多好的起点:


8
ARM7是ARMv4。 ARM9是ARMv4T或ARMv5E。(E表示TDMI) "ARM<数字>"是CPU系列。 "ARMv<数字>"是指令集版本。 - Mads Elvheim

12
你应该明白,ARM授权其知识产权而不是生产芯片。许可证持有人可以以多种方式配置ARM核心微处理器。与你的问题最相关的是,ARM核心本身仅定义了两个中断IRQ和FIRQ,通常有一个特定厂商的中断控制器,因此如果你需要知道如何处理中断,则需要确切地知道你的设备使用了哪个微处理器。iPAQ型号曾经使用过英特尔StrongARM和XScale处理器,如果你想在这个级别上进行开发,你应该下载特定部件的用户参考手册。
所有这些都说了之后,中断服务和设备驱动程序由操作系统提供,所以你可能不需要担心这些低级细节。实际上,我会质疑选择汇编语言作为你的开发语言的选择。在ARM上,很少选择汇编语言而不是C或C++(编译器在代码性能方面几乎肯定会超越你)。此外,在Windows Mobile上,最具生产力的应用级语言可能是C#。

3
编译器在代码性能方面几乎肯定会胜过你。但要让这种情况出现,你必须真的很烂才行。 - J D
2
@Jon:这个观点可能需要一些限定:一个休闲汇编程序员,如果不完全熟悉其指令集和特定的习惯用法,很难超越一个由具有该知识的从业者编写的编译器优化器。能够在生产力方面与优化编译器相媲美的人才的成本和可用性也可能是禁止的。也许你就是那位从业者,或者你所经历的编译器“很差”? ;) - Clifford
1
例如,最近我在ARM Cortex-M3和ARM RealView编译器上实现了一个FIR滤波器,并尝试使用高级C代码中的各种习惯用法来最大化性能。通过使用编译器优化,执行时间减少了一半,并且与供应商手写的汇编DSP库实现相比表现相似。实际上,C实现略微更快,但可能仅因为它针对我们的应用要求进行了优化,而不是通用的。 - Clifford
1
例如,递归浮点斐波那契函数:OCaml(约65条指令)需要14.23秒,F#需要11.23秒,MS VC++需要9.94秒,GCC -O2(约200条指令)需要9.58秒,我的x86汇编器(15条指令)只需要6.82秒。这些编译器都生成了糟糕的x86代码。我知道OCaml在x86上对浮点数很差,但我不知道C++编译器也如此糟糕... - J D
1
@Jon:基准测试是一件危险的事情。大多数计算任务并非如此,编译器更好地针对常见的编程习惯进行性能优化,而不是特定的基准测试。我们需要知道编译器版本和选项以及实际代码才能验证任何结果和测试的有效性/公正性,但考虑到问题是关于ARM的,这可能是离题了。所讨论的iPAQ中的StrongARM处理器甚至没有FPU,因此该数字将受到浮点软件性能而非算法的限制。 - Clifford
显示剩余3条评论

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接