stm32的变量定义，32b是不是效率更高？

gmyu · 发表于 2017-5-15 11:40:50

如题，如果工作再32位模式，是不是32位最好，8位或者16位在读取的时候还要增加移位和对齐操作。

Thumb模式呢？

懂编译器和熟悉ARM的出来说说，主要是M3，乘除法效率方面。

wye11083 · 发表于 2017-5-15 11:50:57

只要你地址是对齐的，访问8/16/32时间是一样的，计算时间也是一样的。。

sunnyqd · 发表于 2017-5-15 11:54:45

是的，32位运算效率最高

sunnyqd · 发表于 2017-5-15 11:56:46

wye11083 发表于 2017-5-15 11:50
只要你地址是对齐的，访问8/16/32时间是一样的，计算时间也是一样的。。

请不要误人子弟，在Cortex-M内核里，32位间的运算的效率最高，除非手写汇编采用8位或16位的SIMD运算

wye11083 · 发表于 2017-5-15 12:03:34

sunnyqd 发表于 2017-5-15 11:56
请不要误人子弟，在Cortex-M内核里，32位间的运算的效率最高，除非手写汇编采用8位或16位的SIMD运算 ...

对arm和mips来说，32位寄存器何来8位16位计算？ld/st进来之后就是32位的值，只是显示转换等等时会再做与操作。我在fpga上移植过一个开源mips核，还改了一些地方提高资源利用率和效率。arm差不多，thumb也只限制了部分指令的访问范围。

myxiaonia · 发表于 2017-5-15 12:08:33

wye11083 发表于 2017-5-15 11:50
只要你地址是对齐的，访问8/16/32时间是一样的，计算时间也是一样的。。

存取时间确实一样，但是8/16位内部干的活更多，尽管都可以在2个时钟完成

但是和乘除法相关的话，一般原生位数的数据会有对应的指令进行乘除，但是8/16位就未必有了

所有比较而言，还是用原生位数的数据类型会更好，而且这也是有依据的，比如c++预定义类型site_t就是原生位数的int

wye11083 · 发表于 2017-5-15 12:17:36

myxiaonia 发表于 2017-5-15 12:08
存取时间确实一样，但是8/16位内部干的活更多，尽管都可以在2个时钟完成

但是和乘除法相关的话，一般原 ...

错也。对这类RISC内核，所有操作都是基于32位的——它里面根本没有16位/8位流水线单元！有符号数LD时做符号扩展，无符号数直接进，然后32位出来，
所以8b/16b并没有多干任何活，反而在一些场合要做&操作，多消耗一个周期。
什么是RISC？顾名思义，越简单越好。至于数据的组织等等，是编译器干的活。基本上优化得当的话，你8位进来，可以说在出来之前，都是32位数在做运算！

takashiki · 发表于 2017-5-15 14:23:25

对于M3来说：

1、M3没有ARM模式，只有Thumb2模式。
2、基本上，在对齐访问模式下，32b访问效率最高，但是LDR等指令相对于8b、16b来说是一样的，因为有专用的指令LDRB、LDRH之类。算数、逻辑运算等等只有32位的操作进行8b、16b运算需要额外的操作而降低效率，但是一般编译器优化之后降低得并不明显。在非对齐访问模式下，32位访问效率比较低，非对齐模式下8位访问效率是最高的，16b、32b需要额外的时钟周期来拼接。因此，__packed关键字是会降低效率的。

gmyu · 发表于 2017-5-15 17:30:29

takashiki 发表于 2017-5-15 14:23
对于M3来说：

1、M3没有ARM模式，只有Thumb2模式。

不知道是不是编译器已经帮我们考虑了对齐和存取的问题。

bias · 发表于 2017-5-15 17:46:45

那是不是变量都用32b最好？对M3

myxiaonia · 发表于 2017-5-15 17:54:07

wye11083 发表于 2017-5-15 12:17
错也。对这类RISC内核，所有操作都是基于32位的——它里面根本没有16位/8位流水线单元！有符号数LD时做符 ...

我所谓的多干的活是指令内部干的活，比如ldrb，其实内部是用ldr获得32位值，然后位屏蔽并选择对应位置的字节，这些操作确实是1个指令就可以完成的，很明显比ldr干的活多嘛

然后乘除运算，我特意去看了下cm3的指令集，乘法倒倒还好，基本上8、16、32位运算都是有对应指令的，但是除法就没有那么幸运了

takashiki · 发表于 2017-5-15 20:00:28

gmyu 发表于 2017-5-15 17:30
不知道是不是编译器已经帮我们考虑了对齐和存取的问题。

不知道呢，我认为编译器应该会尽可能的考虑对齐问题，但是人为的折腾他就没办法了。比如指针强制转换 *(int*) 0x20000001这样的代码。

gonboy · 发表于 2017-5-16 09:17:45

如果不是要求特别严格的地方。完全可以忽略掉差异。

有时不要为了很少的效率，特定将char改成int. 反而可能降低可读性和维护性。

EMC菜鸟 · 发表于 2017-5-16 09:51:27

同意楼上说的，51的那种思维不适合ARM了，没必要去抠那么仔细，代码的可读性、可扩展行、可移植性更重要！

擦鞋匠 · 发表于 2017-5-16 13:56:54

wye11083 发表于 2017-5-15 12:17
错也。对这类RISC内核，所有操作都是基于32位的——它里面根本没有16位/8位流水线单元！有符号数LD时做符 ...

小弟也一直被这个问题困扰...
之前似懂非懂的听人说,使用32位数据格式会提高代码运行速率(尽管其实使用uint8_t就已经可以解决).到现在我也不是很确信...
我现在总结下我理解的区别...
1>占用ram大小的区别,这个显而易见.
2>编译时速度的差异(这个基本上可以无视).
3>我粗略看过CM3权威指南,很多指令都是包含三种方式,如按byte方式,按halfwor方式d,按word操作三种方式.对同一种类型的指令不管采用byte,halfword,word哪种方式,每条指令的执行时间(指令周期)都是一样的,是吧
4>这里小弟还有另外一个疑惑.CM3和CM4是采用Thumb2指令集,而不是Thumb和ARM状态转换的方式,这对效率有何影响(按我理解,如果需要状态切换,当然需要花费额外的时间).
恳请大神指教...

wye11083 · 发表于 2017-5-16 15:09:10

擦鞋匠发表于 2017-5-16 13:56
小弟也一直被这个问题困扰...
之前似懂非懂的听人说,使用32位数据格式会提高代码运行速率(尽管其实使用ui ...

cm不支持arm指令集。。所以只有thumb模式了。
状态切换只要一条ljmp，没有损耗。

擦鞋匠 · 发表于 2017-5-16 15:43:09

wye11083 发表于 2017-5-16 15:09
cm不支持arm指令集。。所以只有thumb模式了。
状态切换只要一条ljmp，没有损耗。 ...

额,大神别嫌小弟啰嗦啊,我还有一个疑问...
在LR寄存器或者PC寄存器中一般特意将LSB置1以表示Thumb状态
我的疑问是:
既然CM3/CM4根本就不支持ARM指令,那么...这一步有什么意义?
难道只是为了跟经典的ARM7处理器兼容???
还是说,置1表示16位Thumb,不置1表示32位Thumb(类似于ARM指令)???
恳请神指教,也请其它神过来围观...

flash3g · 发表于 2017-5-16 15:53:33

感觉还是用uint32_t好点

wye11083 · 发表于 2017-5-16 18:14:19

擦鞋匠发表于 2017-5-16 15:43
额,大神别嫌小弟啰嗦啊,我还有一个疑问...
在LR寄存器或者PC寄存器中一般特意将LSB置1以表示Thumb状态
我 ...

我记得之前在哪个手册里看到的，cm是有那么几条32位指令的——所以绝大多数时候PC的LSB都是1。

stm32的变量定义，32b是不是效率更高？

阿莫论坛20周年了！感谢大家的支持与爱护！！