【烧脑技术贴】无法回避的字节对齐问题，从八个方向深入探讨(变量对齐，栈对齐，DMA对齐，结构体成对齐，Cache, RTOS双堆栈等)
【本文为安富莱电子原创】本期的知识点要稍微烧点脑细胞，因为字节对齐问题涉及到的地方太多，且无法规避，必须硬着头皮上。
下面要说的每个技术点，其实都可以专门开一个帖子说，所以我们这里的讨论，争取言简意赅，并配上官方文档和实验数据，力求有理有据。如果讲解有误的地方，欢迎大家指正，我们主要讨论M0，M0+,M3，M4和M7内核。
static/image/hrline/4.gif
一、引出问题：
字节对齐的含义：4字节对齐的含义就是变量地址对4求余数为0； 8字节对齐就是地址对8求余等于0，依次类推：
比如
uint32_t *p;
p=(uint32_t *)0x20000004; 这个地址是4字节对齐。
如果让p去访问0x20000001， 0x20000002，0x20000003这都是不对齐访问。
static/image/hrline/4.gif
二、背景知识：
对于M3和M4而言，可以直接访问非对齐地址（注意芯片要在这个地址有对应的内存空间),因为M3和M4是支持的，而M0/M0+/M1是不支持的，不支持内核芯片，只要非对齐访问就会触发硬件异常。
https://img.anfulai.cn/dz/attachment/forum/201907/23/011925dtxxy5px01zrrxra.jpg
M7内核也支持非对齐访问，在M7的TRM中描述如下：
https://img.anfulai.cn/dz/attachment/forum/201907/23/010647b5s3eh1ahmzzp7mu.jpg
static/image/hrline/4.gif
三、全局变量对齐问题：
基本上用户定义的变量是几个字节就是几字节对齐，这个比较好理解。
uint8_t定义变量地址要1字节对齐。
uint16_t定义变量地址要2字节对齐。
uint32_t定义变量地址要4字节对齐。
uint64_t定义变量地址要8字节对齐。
指针变量是4字节对齐。
https://img.anfulai.cn/dz/attachment/forum/pw/Fid_45/45_58_a17f387d0f32d03.jpg
https://img.anfulai.cn/dz/attachment/forum/pw/Fid_45/45_58_efe87b5a0ff215d.jpg
static/image/hrline/4.gif
四、结构体成员对齐问题：
首先明白一点，结构体里面的变量是什么类型，此变量的位置就是至少要几字节对齐，所以就存在结构体实际占用大小不是这些变量之和。
typedef struct
{
uint8_t a;
uint16_t b;
uint32_t c;
uint64_t d;
}info;
这种定义，info占用了16字节，a单字节对齐，b是两字节对齐，而c要是4字节对齐，从出现b定义完毕后空出来1个字节未被使用。d是8字节对齐，这样就是16字节。而我们切换下变量定义顺序：
typedef struct
{
uint16_t b;
uint32_t c;
uint64_t d;
uint8_ta;
}info;
这种定义就要占用24字节，b占用2字节对齐，c需要4字节对齐，这样就空出来2两个字节未使用，d占用8字节，最后一个a占用了8字节。
如果想定义几个变量就几个字节，变量前面加前缀__packed即可。
不管是上面那种定义方式，都是占用15个字节。
__packed typedef struct
{
uint8_t a; 1个
uint16_t b; 2个
uint32_t c; 4个
uint64_t d; 8个
}info;
static/image/hrline/4.gif
五、局部变量对齐问题：
局部变量使用的是栈空间（除了静态局部变量和编译器优化不使用栈，直接用寄存器做变量空间），也就是大家使用在xxxx.S启动文件开辟的stack空间。
在M内核里面，局部变量的对齐问题如果研究起来是最烧脑的，这个涉及到AAPCS规约(Procedure Call Standard for the Arm Architecture,Arm架构的程序调用标准)。
上面这个贴图最重要，仅需理解上面这两条就可以，意思是说，栈地址是全程至少保持4字节对齐的，因为M内核的硬件长做了处理，SP最低两个bit，bit0和bit1直接固定为0了。
但是在程序调用入口处必须满足8字节对齐，对于C语言，不需要用户去管，编译器都帮我们处理好了，先来个简单的示例压压惊：
而汇编文件是需要用户去处理的。以xxx.S启动文件为例，通过伪指令PRESERVE8来保证
那么问题来了，我们搞个4对齐是不是会出问题，一般情况下也没问题的，但特殊情况下不行，特别调用C库的sprintf和printf函数，直接给你输出个不知所以然的结果来。比如我在H7上做如下测试：
输出结果：
static/image/hrline/4.gif
六、中断服务程序的栈对齐问题：
先来看两个图：
通过这两个图我们了解到：M0/M0+/M7的栈地址是固定8字节对齐，M3/M4的栈地址是对齐是可以通过SCB->CCR寄存器编程的为4字节或者8字节对齐。
比如我们设置的8字节对齐，那么中断发生的时候，如果SP指针位置在4字节对齐，那么硬件自动插入4字节来保证8字节对齐，之后就是硬件自动入栈的寄存器开始存入栈中。
另外就是不同的M内核硬件版本，这个地方略有不同，这个大家作为了解即可，早期的内核硬件版本应该没什么人用来做芯片了。
static/image/hrline/4.gif
七、硬件浮点对齐问题
如果使用的是带FPU硬件浮点单元的M内核芯片就要注意对齐访问了，访问单精度浮点数访问一定要4字节对齐，双精度要8字节对齐。
比如我们使用支持单精度浮点的M4内核芯片，测试代码如下：
MDK直接给你来个不对齐硬件异常：
static/image/hrline/4.gif
八、RTOS的任务栈：
RTOS的任务栈涉及到双栈指针问题，SP（R13寄存器）有两个栈指针，MSP主栈指针和PSP进程栈指针。简单的说，我们在中断服务程序里面都是用的MSP，而任务里面用的PSP。
优势是方便任务和中断栈空间分别管理，了解了这点知识就够了。
RTOS任务栈的关键依然是8字节对齐问题，如果仅仅是满足4字节对齐，就会出现我们前面printf和sprintf浮点数或者64bit数据的错误问题，早年各种RTOS移植案例还不是那么发达的时候（现在问题依旧），经常在这个地方入坑，加上硬件浮点寄存器入栈出栈后更是玩不转了。
比如大家搜索关键词 uCOS printf 或者uCOS 浮点数，一堆的问题，平时不用浮点不知道，一用浮点，各种问题就来了，特别是多任务都使用浮点计算，更是懵。
根本原因是底层移植文件的堆栈8字对齐有问题，很多人都是采用的指令__align(8)来设置堆栈对齐问题，其实修改底层port文件才是解决问题的根本。
为什么会造成这个问题，根本原因依然是前面AAPCS规约的要求，RTOS的移植都有个汇编的port文件，这个port文件的关键是实现任务切换，任务切换的关键就是进入任务前保证PSP是8字节对齐。
static/image/hrline/4.gif
九、DMA对齐问题：
DMA对齐指的是源数据地址和目的数据对齐问题。这个问题最容易出错的地方就是网上倒腾SD卡移植FatFS的SDIO DMA方式。
大家网上搜关键词FatFS SDIO DMA，也是一瓢的问题，特别是BMP等格式图片显示的时候，这种问题就来了，因为很难保证每次的读取都是4字节对齐的。
以STM32F4的DMA为例，我们的底层移植无需再单独开一个缓冲做4字节对齐，本质是F4 DMA支持了源地址和目的地址的数据宽度可以不同，但是数据地址必须要跟其数据类型对齐。
比如使用SDIO DMA从SD卡读取数据，我们就可以设置源地址依然是4字节对齐(外设访问要4字节对齐)，而目的地址设置为字节对齐，就可以方便的解决4字节对齐问题。
其实不仅是通用的DMA，像图形加速DMA2D，SDMMC自带的IDMA等都有这种问题。
static/image/hrline/4.gif
十、配置MPU造成的对齐问题：
这个问题主要是对于M7内核芯片来说，以STM32H7 TCM以外空间为例：AXI RAM（0x2400 0000），
SRAM1（0x3000 0000），
SRAM2（0x3002 0000），
SRAM3（0x3004 0000），
SRAM4（0x3800 0000），
SDRAM等做非对齐访问都会有硬件异常，而开启Cache就不会有问题。
这个问题的关键就是M7的TRM中这句话：
意思是，如果用户使用MPU将H7的AXI总线下的内存空间配置为Device 或者 Strongly-ordered模式，用户采用非对齐方式访问，将会触发UsageFault
https://img.anfulai.cn/dz/attachment/forum/201907/23/010604leuv4k4cef6efokl.jpg
实际测序下，果然会触发这个异常
https://img.anfulai.cn/dz/attachment/forum/201907/23/010210yooc9co9oczmyo1x.jpg
配置内存空间的MPU属性为Device 和 Strongly-ordered以外的属性就可以解决次问题了。
https://en.wikipedia.org/wiki/Data_structure_alignment
https://developer.arm.com/documentation/ihi0042/latest 做个标记，干货，慢慢研究 这文章太硬，我得晚上回去了消化下。 硬菜，收藏{:34:} 好久没发这种干货技术贴了，非常有价值。 mark
试了，发现个有意思：
非4字节对齐的地址,
通过 结构体指针 来访问浮点数,就没问题.
通过 指向float的指针 来访问浮点数,就会fault 相安无sh 发表于 2021-11-5 08:47
mark
试了，发现个有意思：
非4字节对齐的地址,
方便的话，分享点代码测测:handshake 这两天研究PMU的用法，刚好遇到对齐的问题，学习了
另外问下，下面这个图是在哪个官方文档里的，我查H7的最新手册RM0433里咋没找到MPU的内容呢
浪里个白条 发表于 2021-11-12 11:59
这两天研究PMU的用法，刚好遇到对齐的问题，学习了
另外问下，下面这个图是在哪个官方文档里的，我查H7的 ...
编程手册里面。 干货，那个ucos移植浮点的确是个问题 以上问题基本都遇到过 结构体对齐规则
小麦吉 发表于 2022-1-22 10:43
结构体对齐规则
这里我也是看懵了，停留了好几分钟去研究。 小麦吉 发表于 2022-1-22 10:43
结构体对齐规则
规则第三条应该能解释，20无法被8整除，因此需24字节 小麦吉 发表于 2022-1-22 10:43
结构体对齐规则
本来最后a只占一个字节，由于要满足整体大小要是最大成员（d）的整数倍，所以整体从17（4+4+8+1）变成24(4+4+8+8)
规则:
（1）、整体空间是占用空间最大的成员（的类型）所占字节数的整数倍。
（2）、数据对齐原则---内存按结构体成员的先后顺序排列，当排到该成员时，其前面已摆放的空间大小必须是该成员类型大小的整数倍，如果不够则补齐，依次向后类推。
关于RTOS对齐这章节，Freertos创建栈的时候会自动会向下做8字节对齐，这样就能保证PSP是8字节对齐的。
pxTopOfStack = ( StackType_t * ) ( ( ( uint32_t ) pxTopOfStack ) & ( ~( ( uint32_t ) 0x0007 ) ) );
感谢楼主，非常好的文章。
用msvc编译器 显示也是24BYTES.硬汉哥真牛比;P 太强了，Mark 烧脑 这种硬核文章必须评论码住，有问题就来观摩 必须mark，已经遇到对齐问题了 IEEE 754？ frazer1993 发表于 2022-11-20 21:21
IEEE 754？
AAPCS 刚好上次研究过， mark学习 硬汉哥，咨询下在M7内核下使用memcpy导致进入hardfault，也是字节未对齐导致的吗 ZHENG999 发表于 2023-8-14 09:44
硬汉哥，咨询下在M7内核下使用memcpy导致进入hardfault，也是字节未对齐导致的吗
对，也是的，就我楼主位帖的第10个：配置MPU造成的对齐问题 http://www.catb.org/esr/structure-packing/
“M0/M0+/M7的栈地址是固定8字节对齐，M3/M4的栈地址是对齐是可以通过SCB->CCR寄存器编程的为4字节或者8字节对齐。”这句话是针对中断程序入口的栈地址对齐规则还是全程栈地址？ qq1646544 发表于 2023-10-24 16:09
“M0/M0+/M7的栈地址是固定8字节对齐，M3/M4的栈地址是对齐是可以通过SCB->CCR寄存器编程的为4字节或者8字 ...
不仅是中断，函数调用也是，这些都是编译器帮我们处理好了。
而移植RTOS的时候，就需要用户单独设置任务栈8字节对齐。 DMA对齐有点闹不清楚，当递增量大于1时，是不是源地址和目标地址必须和各自的位宽对齐？ DX3906 发表于 2023-11-3 10:58
DMA对齐有点闹不清楚，当递增量大于1时，是不是源地址和目标地址必须和各自的位宽对齐？
对，一定要和各自设置的位宽对齐。 结构体那说的是啥玩意 spear47 发表于 2023-12-18 11:35
结构体那说的是啥玩意
结构体成员的字节对齐问题。
结构体成员由于字节对齐问题访问出现异常时，要查看这个。
硬汉哥，这两份文档可以上传一下吗？网上不找针对性找 wdliming 发表于 2024-1-15 14:56
硬汉哥，这两份文档可以上传一下吗？网上不找针对性找
楼主位帖子的文档吗，还是楼主位里面用到的文档。 就是上面英文文档可以分享吗？ wdliming 发表于 2024-1-15 22:10
就是上面英文文档可以分享吗？
这个是M4权威指南上的。
Cortex-M4，M3，M0权威指南（中英文版）
https://www.armbbs.cn/forum.php?mod=viewthread&tid=96973&fromuid=58
(出处: 硬汉嵌入式论坛)
页:
[1]
2