乱序和屏障2 : UP单核需要处理的CPU乱序问题

前言

UP : (Uni-Processor)
 
编译器乱序 对应的 编译器 内存屏障 问题 已经在 https://blog.csdn.net/u011011827/article/details/124563277
中提及, 并 做了实验

接着 我们 讨论一下 单核需要处理的CPU乱序问题
这个和架构相关
我们主要考察 arm32/arm64/rv32/rv64
他们都是弱内存顺序模型 , 我们先就 弱内存顺序模型考察一番

弱内存顺序模型

对 load & store 的执行顺序没有要求, 只要不将依赖相关的指令乱序,则可以任意乱序
例如 如下,只要没有依赖,都可以乱序(但不一定100%乱序) // 格式为 before-store
load-load
store-store
load-store
store-load

屏障指令的封装

rmb/wmb/mb

读内存屏障
	本线程所有后续的读操作均在本条指令以后执行
写内存屏障
	本线程所有之前的写操作均在本条指令以前执行
读写内存屏障
	本线程所有之前的读写操作均在本条指令以前执行

armv7

注意 : ARMv7 没有 LD 选项 . ARMv8 有

以Inner Shareable(ISH)为例

使用"SY"
	可防止 所有的 的reorder (read&write memory barrier)
		load-load
		store-store
		load-store
		store-load
使用"ST"
	防止以下的乱序 (write memory barrier)
		store-store

#define dsb(opt) __asm__ __volatile__ ("dsb " #opt : : : "memory")
#define mb()            dsb() // 等同于 dsb(sy)
#define rmb()           dsb() // 等同于 dsb(sy)
#define wmb()           dsb(st)

ARMv8

write-read 即 store-load 没必要 屏障吗?
	没有必要 // TODO
	如果有依赖,自然不会乱序
	如果没有依赖,store什么时候发生以及完成都无所谓

#define dsb(opt) __asm__ __volatile__ ("dsb " #opt : : : "memory")
#define mb()            dsb(sy)
#define rmb()           dsb(ld)
#define wmb()           dsb(st)

RV32&RV64

#define RISCV_FENCE(p, s) \
        __asm__ __volatile__ ("fence " #p "," #s : : : "memory")

#define mb()            RISCV_FENCE(iorw,iorw)
#define rmb()           RISCV_FENCE(ir,ir)
#define wmb()           RISCV_FENCE(ow,ow)

mb/rmb/wmb 的应用

执行流分析

如果只有一个执行流,应该没啥问题, 因为 有依赖关系的指令 不会乱序
	如果我改了下一条指令呢?是不是要 刷新一下流水线

目前 我的代码里面有两个 执行流
	一个是正常的用户执行流
	一个是异常执行流
那么就考虑 mb/rmb/wmb 在 两个执行流中会导致的问题

情景1 单用户流

不加屏障的情况
	command1 	// 改了 command3 所在的地址 的指令 为 异常产生指令(svc/ecall)
	command2    // nop 指令
	command3 	// command3 指令(待修改 为 svc/ecall)
加了屏障的情况
	command1 	// 改了 command3 所在的地址 的指令 为 异常产生指令(svc/ecall)
	command2    // mb 指令
	command3 	// command3 指令(待修改 为 svc/ecall)


结果 :
	不加屏障 : command3 已经被加载到 pipeline , 还是执行 原来的 command3
	  加屏障 : command3 已经被加载到 pipeline , 然后flush pipeline , 执行 svc/ecall
实验代码:
	https://gitee.com/suweishuai/baremetal/commit/b5bd7565c84bf4ad69e4773719b8d6082df086ef

情景2 用户流与异常流

// 初始化 flag = 0 ;
// 初始化 data = 0 ;
User:
	while (flag == 0);  	// U1
	printf("%d\n",data); 	// U2
Execption:
	data = 0x200;			// E1
	flag = 1;  				// E2

会有两个问题:
	Q1 :User flow 里面  U2 先于 U1 执行 ? 
	Q2 :Execption flow 里面 E2 先于 E1 执行, E1 还未执行,此时 Execption 切出,然后 U1 U2 执行,打印 了 0

Q1 可以测试
Q2 不可测试(因为Execption 不会在那时切出) // 只有 如下情况才可测试
	UserA:
		while (flag == 0);  	// UA1
		printf("%d\n",data); 	// UA2
	UserB:
		data = 0x200;			// UB1
		flag = 1;  				// UB2
	UserB flow 里面 UB2 先于 UB1 执行, UB1 还未执行,此时 UserB 切出,然后 UA1 UA2 执行,打印 了 0

Q1 实际情况 // 在四种架构下都不会有 U2 先于 U1 执行 的情况 , 这里拿aarch64来说
	U1 反汇编 为 U1.1 U1.2 U1.3
	U2 反汇编 为 U2.1 U2.2 U2.3 U2.4
	// 看起来也没有依赖,为什么不会发生乱序呢? // TODO
	40005e44:   b9402be0    ldr w0, [sp, #40]  					// U1.1
	40005e48:   7100001f    cmp w0, #0x0 						// U1.2
	40005e4c:   54ffffc0    b.eq    40005e44 <new_fun+0x74>     // U1.3
	40005e50:   b94027e1    ldr w1, [sp, #36] // 开始准备调用 printf  	// U2.1
	40005e54:   f0000000    adrp    x0, 40008000 <__func__.0+0x2a8>		// U2.2
	40005e58:   91272000    add x0, x0, #0x9c8  						// U2.3
	40005e5c:   97fff414    bl  40002eac <printf> 						// U2.4