CortexM3的指令都是32/16位的吧

只看该作者 · 2014-6-19 12:21

今天看CM3权威指南，其指令集都是32/16位的，如果操作char 这种8位的数据，就要扩展成16或32位，这样会降低了时间效率吧？
那是否应该多用uint16_t之类的数据类型，少点使用uint8_t 呢？

只看该作者 · 2014-6-19 14:13

不能看指令长度，要看指令能操作的寄存器的宽度，不算某些dsp指令的话，cm3能操作的寄存器宽度都固定是32位的。就是说8位和16位的都要扩展到32位。
但这并不是说任何数据都定义为32位就好，本身是8/16位的数据强行定义为32位，一是C语言可能没法表达，比如字符串，它就是8位的，搞不到32位上去；二是即使能表达，也浪费存储空间。
仔细看看arm/thumb/thumb2指令集，可以发现在内存中的数据，不管8/16/32位都可以直接装载到寄存器中，寄存器也可以直接保存到8/16/32位的RAM中，不需要多余的指令。
所以我建议这样，如果某数据的定义空间，你确定它是在内存里（全局或堆），你就按数据本身的需要定义，该8位就8位。如果是局部变量（栈或寄存器），就定义为uint32_t；如果是聚集类型（struct/union等等）中的成员，也按本身定义。
多说一点，如果要多考虑一些移植性带来的效率和开销问题，那么还有一些标准的预定义数据类型可用（在stdint.h中）：
uint_fast8_t，uint_fast16_t 等等，这些类型建议只用来定义局部变量和函数的形参。
这些类型考虑了不同CPU的寄存器的不同宽度问题，以获得最佳效率和适当开销。
比如在arm上，寄存器都是32位的，那么uint_fast8_t就与uint32_t是等同的。
而在8位的CPU，比如avr上，uint8_fast8_t与uint8_t就是等同的。

只看该作者 · 2014-6-19 15:33

john_lee 发表于 2014-6-19 14:13
不能看指令长度，要看指令能操作的寄存器的宽度，不算某些dsp指令的话，cm3能操作的寄存器宽度都固定是32位 ...

多谢指教！

只看该作者 · 2014-6-19 19:16

CM3指令集里面访问4字节对齐地址速度最快，uint32_t缺省是4字节对齐的，而uint8_t则不是，访问不在4字节对齐地址的uint8_t会插入一个时钟，第一次访问4字节对齐地址放弃结果，第二次访问相对于4字节对齐的偏移量。所以uint8_t的操作会比uint32_t慢一些。

1万 · 2014-6-19 20:03

楼上的说法不准确. 访问 uint8_t 肯定不需要额外的时钟. 如果 16 位或者 32 位, 并且没有地址对齐, 才会分成两次访问, 出现额外的时钟.
我还是建议尽量使用 8 位变量, 因为8位常数处理大都使用 16 位指令, 而 16 位则使用 32 指令, 32 位则额外地使用ROM 常数, flash 空间肯定会大.

只看该作者 · 2014-6-19 20:22

airwill 发表于 2014-6-19 20:03
楼上的说法不准确. 访问 uint8_t 肯定不需要额外的时钟. 如果 16 位或者 32 位, 并且没有地址对齐, 才会分 ...

对于CM3的uint32_t如果没4字节对齐直接就是usagefault，哪来什么额外时钟？

1万 · 2014-6-19 22:11

李富贵发表于 2014-6-19 20:22
对于CM3的uint32_t如果没4字节对齐直接就是usagefault，哪来什么额外时钟？

楼上可能记错了.
uint32_t如果没4字节对齐直接就是 usagefault，这是 CM0.
看 Cortex-M3™ Revision: r0p0 Technical Reference Manua
14.4.1 Unaligned accesses
Unaligned data and debug accesses are converted into two or three (depending on the size and alignment of the unaligned access) aligned accesses. This stalls any subsequent accesses until the unaligned access has completed. For a description of unaligned accesses, see Access alignment on page 14-9.