加入星计划,您可以享受以下权益:

  • 创作内容快速变现
  • 行业影响力扩散
  • 作品版权保护
  • 300W+ 专业用户
  • 1.5W+ 优质创作者
  • 5000+ 长期合作伙伴
立即加入
  • 正文
    • 1 前言
    • 2 preservedprogram order
    • 3 memory model axiom
    • 4 总结
  • 相关推荐
  • 电子产业图谱
申请入驻 产业图谱

RISC-V笔记——内存模型总结

10/21 08:50
373
阅读需 8 分钟
加入交流群
扫码加入
获取工程师必备礼包
参与热点资讯讨论

1 前言

Memory consistency model定义了使用Shared memory(共享内存)执行多线程(Multithread)程序所允许的行为规范。RISC-V使用的内存模型是RVWMO(RISC-V Weak Memory Ordering),RVWMO内存模型是根据全局内存顺序(global memory order)定义的,全局内存顺序是所有harts产生的内存操作的总顺序。通常,多线程程序有许多不同的可能执行,每个执行都有自己对应的全局内存顺序。

全局内存顺序是通过内存指令生成的基本load和store操作来定义的。内存操作的程序顺序(program order)反映了生成每个load和store的指令在该处理器的动态指令流中逻辑布局的顺序。例如:一个简单的有序处理器执行该处理器指令的顺序。在分析任何一个内存模型时,要紧紧抓住全局内存顺序和程序顺序去分析。

当一个load的返回值确定时,我们就说它已经执行了。当store在pipeline内执行时,不是说它执行了,只有当它的值被传播到全局可见内存时才执行。从这个意义上说,全局内存顺序也代表了一致性协议和/或内存系统的其他部分的贡献,将每个hart发出的(可能是重新排序的)内存访问交错到所有hart共同的单个总顺序中。

RISC-V的RVWMO模型主要包含了preserved program order(PPO)、load value axiom、atomicity axiom和progress axiom。preserved program order由Overlapping-Address Orderings、Explicit Synchronization、Syntactic Dependencies和Pipeline Dependencies组成的。load value axiom、atomicity axiom和progress axiom三者共同组成了memory model axiom。

2 preservedprogram order

任何给定的程序执行的全局内存顺序都遵循每个hart的部分(但不是全部)程序顺序。全局内存顺序必须遵守的程序顺序的子集称为保留程序顺序(preserved program order)。从概念上讲,如果一个hart的某段程序时保留程序顺序,那么这段程序必须被其它hart以相同的顺序观察到。另一方面,从其它hart角度来看,来自一个hart的未按保留的程序顺序排序的事件可能看起来是重新排序的。

保留程序顺序的完整定义如下(请注意,AMOs是同时load和store的):如果a在程序顺序中先于b,内存操作a在保留程序顺序中先于内存操作b(因此也在全局内存顺序中),且a和b都访问常规主存,不是I/O区域,并且以下任何一种情况(每个小节)都有效:

2.1 Overlapping-Address Orderings

请看:RISC-V笔记——重叠地址排序

2.2 Explicit Synchronization

请看:RISC-V笔记——RVWMO基本体 和 RISC-V笔记——显式同步

2.3 Syntactic Dependencies

请看:RISC-V笔记——语法依赖

2.4 Pipeline Dependencies

请看:RISC-V笔记——Pipeline依赖

3 memory model axiom

memory model axiom(内存模型公理)是RVWMO的重要组成部分。它由以下三部分组成。

load value axiom

atomicity axiom

progress axiom

这三者的介绍在这篇文章:RISC-V笔记——内存模型公理

4 总结

内存一致性模型有弱和强之分。弱内存模型允许更多的硬件实现灵活性,并且比强模型提供更好的性能、每瓦性能、功率、可伸缩性和硬件验证开销,但代价是更复杂的编程模型。强模型提供了更简单的编程模型,但代价是对可以在pipeline和内存系统中执行的(非投机的)硬件优化施加了更多的限制,并且反过来在功耗、面积开销和验证负担方面施加了一些成本。

RVWMO是一种弱模型,它使架构师能够构建简单有效地实现、深入嵌入更大的系统并服从复杂的内存系统交互的实现,或者任何其他可能性,并高效地支持编程语言内存模型。

为了方便从其他体系结构移植代码,一些硬件实现可能会选择实现Ztso扩展,该扩展在默认情况下提供更严格的RVTSO排序语义。为RVWMO编写的代码自动地和固有地与RVTSO兼容,但是假设RVTSO编写的代码不能保证在RVWMO实现上正确运行。事实上,大多数RVWMO实现将(也应该)拒绝只运行RVTSO的二进制文件。因此,每个实现都必须选择是否优先考虑与RVTSO代码的兼容性(例如,为了便于从x86移植)。

在RVTSO下,为RVWMO编写的代码中的一些fence或memory排序可能变得多余。RVWMO对ZTSO实际造成的成本是取值这些fence指令的开销,例如FENCE R,RW和FENCE RW,W,这些指令在该实现上变成NoP操作。但是,如果希望与非ZTSO实现兼容,则这些fences必须保留在代码中。

相关推荐

电子产业图谱

分享Arm architecture, AMBA, 芯片验证, 脚本, EDA, Linux等知识。

微信公众号