隔壁Cortex-M0也不支持非对齐地址访问,代码中uint8_t*指针一旦强转uint16_t*或者uint32_t*,很容易引起HardFault。然而M3/M4就支持非对齐地址访问了,很多历史代码中会存在上面的强制地址转换,M3和M4上运行正常的代码移植到RISC-V以后非常容易踩到地址对齐的坑,代码规模比较大的时候填这些坑还是非常麻烦的。
RV32MAC假想对手是整个Cortex-M系列,M0是整个Cortex-M里面最低端的系列,RISC-V起码应该和M3/M4差不多,非对齐地址访问起码应该作为一个选项存在。
离线
是否支持非对齐访问,是实现层面的问题,,RISC-V ISA 本身并不限制是否支持非对齐访问。。
离线
《手把手教你设计CPU——RISC-V处理器》上的说明
离线
是否支持非对齐访问,是实现层面的问题,,RISC-V ISA 本身并不限制是否支持非对齐访问。。
人家隔壁ARM M0/M3/M4是不是支持是规定了的,这种模棱两可,依赖厂家来实现对齐、非对齐结果就是碎片化。RISC-V应该有一个扩展来约束是否支持非对齐访问操作。
离线
对齐不对齐,是软件设计方面的问题。
另外,非对齐数据,访问会需要更多的时间周期。
自己设计软件的时候,尽量把数据放在对齐地址上。
同样功能的代码,有些人的代码跑得就是比别人的快,这是有原因的。
离线
编译器应该可以处理
离线
GCC编译器的特定优化选项会自动将不对齐的操作转为对齐操作。
离线
GCC编译器的特定优化选项会自动将不对齐的操作转为对齐操作。
编译器能力是有限的,uint8_t*指针强制转换uint32_t*编译器就无法处理,大概率会跪。很多解析二进制数据的代码都会这么干。规模庞大的代码填这些坑就非常麻烦。
离线
非对齐操作即使支持也应该回避,这所以产生非对齐操作无非是想减少内存复制,但非对齐操作性能太低,不如复制内存对齐起来跑得更快。
最近编辑记录 海石生风 (2023-01-06 11:31:57)
离线