汇编程序设计-汇编程序设计的格式是什么 收藏 0

volatile很难？由浅入深怼到CPU汇编，彻底搞清楚它的底层原理

Tips：最近面试，但凡是个像样的公司面试官都得问我对volatile关键字理解以及其实现原理。虽然多多少少知道一些，但是问深了，终究感觉还是差了那么一点，所以这次我要把这个关键字来学个通透！

本文记录个人学习volatile。主要包含以下内容，力求简单明了：

1. 一段代码来演示问题背景
2. volatile解决内存可见性问题
3. Java内存模型原子操作
4. 总线加锁太慢？MESI缓存一致性协议（总线嗅探机制）
5. 彻底掌握volatile底层原理

点击运行，会有如下输出：

可以知道的是，线程1在无限空转，只有当flag=true才会跳出，但是线程2对flag的改变，线程1却感知不到。。。

使用top命令也可以看到有一个Java进程的CPU在100%上下：

在了解上面的代码运行原理之前，我们需要知道现代计算机多核CPU并发缓存架构：

那么问题来了！CPU缓存是什么东西？现代的CPU和主内存之间都会有CPU高速缓存来解决一个内存和CPU二者之间速度不匹配问题：主内存的速度跟不上CPU的高速运行。

上图是计算机组成原理，大学肯定学过，现在的状态就是：看到了来一句“我kao，这玩意我知道啊！”，看不到的时候从来想不起来。。。

那么在Java线程内存模型中，其实和CPU缓存模型是一个意思，是基于CPU缓存模型来建立的：

结合上图来看，文中的代码段运行步骤应该是这样的：

1. 将静态全局变量flag加载到主内存中;
2. 线程1从主内存中读取变量flag到自己的工作内存中，即工作变量副本，值为false；
3. 线程2从主内存中读取变量flag到自己的工作内存中，值为false；
4. 线程1无限空转；
5. 线程2将变量flag值置为true,并刷新回主内存。

核心问题：线程2对变量flag的改变对线程1不可见！

问题已经很清晰，那么怎么能让线程1能够顺利的跳出while循环呢？

只要对flag变量加volatile关键字修饰即可让线程1跳出while循环：

那么volatile关键字到底在我们的多线程程序运行时候是怎么来保证线程见的可见性呢？几个问题：1、多线程程序底层是怎么执行的？2、主内存和工作内存是怎么交互的？3、为什么volatile关键字就可以保证各线程对变量的可见性？

Java内存模型定义了如下8种原子操作来实现主内存和工作内存之间的交互协议：

• read(读取)：从主内存读取数据
• load(载入)：将主内存读取到的数据写入工作内存
• use(使用)：从工作内存读取数据来计算
• assign(赋值)：将计算好的值重新赋值到工作内存中去
• store(存储)：将工作内存数据写入到主内存
• write(写入)：将store过去的变量赋值给主内存中的变量
• lock(锁定)：将主内存变量加锁，标识为线程独占状态
• unlock(解锁)：将主内存变量解锁，解锁后其他线程可以锁定该变量

这里一定要注意的关键词是原子操作，原子操作意味着，当我们对主内存的共享变量进行原子操作的时候，它一定是线程安全的！

将以上8个原子操作映射到上面的程序，来看看上面程序的线程内存模型是什么样子的，如下图所示：

线程1的操作（红色路线）：

1、read——从主内存读取到数据：flag=false；

2、load——将读取到的flag=false数据写入到线程1的工作内存；

3、use——使用工作内存中的flag=false数据：while(!flag)。

线程2的操作（橙色路线）：

1、read——从主内存读取到数据：flag=false；

2、load——将读取到的flag=false数据写入到线程2的工作内存；

3、use——使用工作内存中的flag=false数据；

4、assign——设置flag=true，并重新赋值到线程2的工作内存；

5、store——将工作内存中的flag=true写入到主内存；

6、write——将写入到主内存中的flag=true设置到主内存的变量。

根据这两个线程的操作步骤，可以看到虽然线程2将主内存中的flag变量值变成true了，但是线程1根本就不知道，只有第一次read到的值才有效，这就是本质原因。

所以我们可以思考一下，如何才能让线程1感知到其他线程（线程2）对变量flag的更改呢？

1. 加锁：同一个时间点只有一个线程能read到flag这个变量，当其他线程去获取这个变量时候，只能是等待；
2. 事件响应模式：多个线程都可以read到flag这个变量，但是当有任何一个线程修改了这个变量的值，需要通知其他线程，使得自己工作内存中的缓存数据失效。

是不是这两种思想？这两种思想是不是有点熟悉？是不是感觉好多地方都是这种套路？比如I/O模型中的select和epoll，还有没有其他场景也是这种套路呢？

早期在CPU层面为了解决共享变量多线程之间副本不可见的问题，就是总线加锁的方式：

和之前有变化的就是：

• read之前对该变量加锁lock
• write之后对该变量释放锁unlock

这样就能保证其他的CPU（线程）在读取该变量的时候只能是等待状态，但是问题也来了，在操作同一个变量时候，原来我们是一个多线程的程序，因为加锁的原因，使得我们的程序又是单线程串行执行了，也就是所谓的锁粒度太粗。

上面的问题就是一棍子打死，只要一个线程获取了主内存中的变量，其他线程都得在等待，这就错杀了很多线程，有可能一个线程只是需要读取一下，或者很多读多写少的场景都不满足。

那么怎么优化呢？套路都是一致的：

• 降低锁粒度：只在需要加锁的时候加锁
• 事件响应机制：当有线程对共享变量有更改后，让其他线程能够感知到从而让自己本地工作内存中的缓存失效

这个思想就是CPU中的MESI缓存一致性协议：

多个CPU从主内存读取同一个数据到各自的高速缓存，当其中某个CPU修改了缓存里的数据，该数据会马上同步回主内存，其他CPU通过总线嗅探机制可以感知到数据的变化从而将自己缓存里的数据失效。

了解清楚上面的思想和原理后，其实volatile就是借助了CPU的MESI缓存一致性协议的原理。还是看上面的那段代码，当对flag变量增加volatile修饰后，我们通过查询该类的汇编码指令，可以得到下面这部分汇编指令：

对应的就是上面程序的代码：

所以volatile关键字在汇编底层的实现原理就是通过汇编lock前缀指令。

IA-32架构软件开发手册对lock指令的解释：1、会将当前处理器缓存行的数据立即写回到系统内存2、这个写回内存的操作会引起其他CPU里缓存了该内存地址的数据无效（即MESI协议）

翻译成人话就是（还是上面的程序代码）：

1、flag变量被volatile修饰了；

2、当线程2对flag做assign操作后需要立即写回主内存；

3、在store之前，该lock指令会对内存中的变量flag加一把锁；

4、当store操作将flag值写回主内存时候，需要通过CPU总线，这个时候会触发总线嗅探机制，通知其他CPU缓存失效；

5、执行write成功后，会执行unlock释放锁。

根据上述描述，可以发现锁粒度小很多了，只在store时候加锁，而不是像直接锁总线那样粗。

关于volatile的学习，本文就到这里，但是还没有结束。我相信只要你认真的看到这里，你一定有所收获，了解并掌握这些最最最底层、基础的原理和思想之后，后面关于volatile的学习一定是畅通无阻的！关于volatile的更多知识：

1. 并发编程的三大特性：可见性、原子性、有序性，volatile无法保证原子性，原子性需要synchronize来保证；
2. volatile如何保证有序性？
3. 禁止指令重排序、JSR内存屏障。

我们继续学习，感兴趣的同学可以关注我，持续获取更多技术干货文章～

LCD汉字显示屏的硬件电路与汇编语言程序设计

一、电路原理图

二、电路简介

1、OCMJ2X8（128X32）引脚说明

2、硬件接口

接口协议为 请求/应答（REQ/BUSY） 握手方式。应答BUSY 高电平（BUSY =1） 表示 OCMJ 忙于内部处理，不能接收用户命令；BUSY 低电平（BUSY =0）表示 OCMJ 空闲，等待接收用户命令。发送命令到 OCMJ可在BUSY =0 后的任意时刻开始，先把用户命令的当前字节放到数据线上，接着发高电平REQ 信号（REQ =1）通知OCMJ请求处理当前数据线上的命令或数据。OCMJ模块在收到外部的REQ高电平信号后立即读取数据线上的命令或数据，同时将应答线BUSY变为高电平，表明模块已收到数据并正在忙于对此数据的内部处理，此时，用户对模块的写操作已经完成，用户可以撤消数据线上的信号并可作模块显示以外的其他工作，也可不断地查询应答线BUSY是否为低（BUSY =0？），如果BUSY =0，表明模块对用户的写操作已经执行完毕。可以再送下一个数据。如向模块发出一个完整的显示汉字的命令，包括坐标及汉字代码在内共需5个字节，模块在接收到最后一个字节后才开始执行整个命令的内部操作。

1）显示国标汉字

命令格式： F0 XX YY QQ WW

该命令为5字节命令（最大执行时间为1.2毫秒，Ts2=1.2mS），其中

XX：为以汉字为单位的屏幕行坐标值，取值范围00到07、02到09、00到09

YY：为以汉字为单位的屏幕列坐标值，取值范围00到01、00到03、00到04

QQ WW：坐标位置上要显示的GB 2312 汉字区位码

2) 显示8X8 ASCII字符

命令格式：F1 XX YY AS

该命令为4字节命令（最大执行时间为0.8毫秒，Ts2=0.8mS），其中

XX：为以ASCII码为单位的屏幕行坐标值，取值范围00到0F、04到13、00到13

YY：为以ASCII码为单位的屏幕列坐标值，取值范围00到1F、00到3F、00到4F

AS：坐标位置上要显示的ASCII 字符码

3) 显示8X16 ASCII字符

命令格式：F9 XX YY AS

该命令为4字节命令（最大执行时间为1.0毫秒，Ts2=1.0mS），其中

XX：为以ASCII码为单位的屏幕行坐标值，取值范围00到0F、04到13、00到13

YY：为以ASCII码为单位的屏幕列坐标值，取值范围00到1F、00到3F、00到4F

AS：坐标位置上要显示的ASCII 字符码

4) 显示位点阵

命令格式： F2 XX YY

该命令为3字节命令（最大执行时间为0.1毫秒，Ts2=0.1mS），其中

XX：为以1*1点阵为单位的屏幕行坐标值，取值范围00到7F、20到9F、00到9F

YY：为以1*1点阵为单位的屏幕列坐标值，取值范围00到40、00到40、00到40

5) 显示字节点阵

命令格式： F3 XX YY BT

该命令为4字节命令（最大执行时间为0.1毫秒，Ts2=0.1mS），其中

XX：为以1*8点阵为单位的屏幕行坐标值，取值范围00到0F、04到13、00到13

YY：为以1*1点阵为单位的屏幕列坐标值，取值范围00到1F、00到3F、00到4F

BT：字节像素值，0 显示白点，1 显示黑点 （显示字节为横向）

6) 清屏

命令格式：F4

该命令为单字节命令（最大执行时间为11毫秒，Ts2=11mS），其功能为将屏幕清空。

7) 上移

格式：F5

该命令为单字节命令（最大执行时间为25毫秒，Ts2=25mS），其功能为将屏幕向上移 一个点阵行。

8) 下移

命令格式：F6

该命令为单字节命令（最大执行时间为30毫秒，Ts2=30mS），其功能为将屏幕向下移动一个点阵行。

9) 左移

命令格式：F7

该命令为单字节命令（最大执行时间为12毫秒，Ts2=12mS），其功能为将屏幕向左移动一个点阵行。

10) 右移

命令格式： F8

该命令为单字节命令（最大执行时间为12毫秒，Ts2=12mS），其功能为将屏幕向右移动一个点阵行。

四、装配要求和方法

1、实验连线：8255的PA0~PA7接DB0~DB7，PC7接BUSY，PC0接REQ，CS8255接CS0。

2、程序流程：

编程语言-什么是低级语言？

信息的有效传递至少需要传递者、接收者、共识信息等才能构成一个闭环，举个栗子（如下图）：

信息在上图中其实就是 ‘中文’，共识的意思就是都能听的懂，下图是一个无效的信息传递：

人们想要和计算机打交道并且让计算机帮助我们去做一些事情时，作为主动传达信息的人们则需要‘说’一些计算机能听懂的‘语言’（0010100110）也就是常说的编程语言。

计算机早期的时候人们的目的只有一个，让计算机能听懂就行，于是就有了早期的编程语言-机器语言（Machine Language）

机器语言有个特点就是由0和1组序列组成的指令码，如下示例：

好了，计算机这回算是听的懂人们说的了，但是程序员们可要忙坏了[吐]

许多繁杂琐碎的细节牵制着程序员，即使智力超群的程序员也常常会顾此失彼，屡出差错，因而所编出的程序可靠性差，且开发周期长。因此机器语言也被称为 低级语言（相对）

人们的思想一直在演变与进步，为了更加友好地写出计算机能听得懂的语言，于是就有了第二代编程语言–汇编语言（Assembly Language），其特点是用一些容易理解和记忆的字母，单词来代替一个特定的指令

下面是用汇编语言实现的输出 ‘Hello World！’ 先来感受一下（左右滑动有注释）

目测一下，汇编语言比起机器语言仅仅只是在编写量和程序员维护起来方便了那么一丢丢，其编写层面上还是要懂得CPU运行、内存空间加载的原理，还是直接操作硬件来传达信息，并没有什么实质上的改变。

因此汇编语言和机器语言一样都被称为 低级语言。

优点对比总结：

机器语言：编写的程序指令（1100101001）可以被计算机无障碍理解并直接运行，没有中间商赚差价，效率贼高。

汇编语言：使用易懂的英文编写，执行效率比机器语言稍低（仍然是直接操作硬件）

缺点对比总结：

机器语言：仍然是直接操作硬件，因此开发复杂效率低跨平台性差

汇编语言：同上

万物星辰都在不断演变，如今我们谈论到的低级语言是站在现在环境的角度去评价的，然而在语言的诞生时代，是非常有意义的，现在今后也一样。

更多精彩内容请关注 公众号：数据与编程之美

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com