输入输出

Last updated 6 years ago

Was this helpful?

输入输出

我们已经成功运行了各个cputest中的测试用例, 但这些测试用例都只能默默地进行纯粹的计算. 回想起我们在程序设计课上写的第一个程序hello, 至少也输出了一句话. 事实上, 输入输出是计算机与外界交互的基本手段, 如果你还记得计算机刚启动时执行的BIOS程序的全称是Basic Input/Output System, 你就会理解输入输出对计算机来说是多么重要了. 在真实的计算机中, 输入输出都是通过I/O设备来完成的.

设备的工作原理其实没什么神秘的. 你会在不久的将来在数字电路实验中看到键盘模块和VGA模块相关的verilog代码. 噢, 原来这些设备也一样是个数字电路! 事实上, 只要向设备发送一些有意义的数字信号, 设备就会按照这些信号的含义来工作. 让一些信号来指导设备如何工作, 这不就像"程序的指令指导CPU如何工作"一样吗? 恰恰就是这样! 设备也有自己的状态寄存器(相当于CPU的寄存器), 也有自己的功能部件(相当于CPU的运算器). 当然不同的设备有不同的功能部件, 例如键盘有一个把按键的模拟信号转换成扫描码的部件, 而VGA则有一个把像素颜色信息转换成显示器模拟信号的部件. 这些控制设备工作的信号称为"命令字", 可以理解成"设备的指令", 设备的工作就是负责接收命令字, 并进行译码和执行... 你已经知道CPU的工作方式, 这一切对你来说都太熟悉了. 唯一让你觉得神秘的, 就要数设备功能部件中的模/数转换, 数/模转换等各种有趣的实现. 遗憾的是, 我们的课程并没有为我们提供实践的机会, 因此它们成为了一种神秘的存在.

我们希望计算机能够控制设备, 让设备做我们想要做的事情, 这一重任毫无悬念地落到了CPU身上. CPU除了进行运算之外, 还需要与设备协作来完成不同的任务. 要控制设备工作, 就需要向设备发送命令字. 接下来的问题是, CPU怎么区分不同的设备? 具体要怎么向一个设备发送命令字?

对第一个问题的回答涉及到I/O的编址方式. 我们知道内存有地址的概念, 类似地, 我们也可以给I/O设备中允许CPU访问的寄存器逐一编址. I/O编址的目的就是让CPU可以区分不同的设备, 尽管这种区分的方式在我们来看非常笨拙: 只是让不同的设备报个数而已.

一种I/O编址方式是端口映射I/O(port-mapped I/O), CPU使用专门的I/O指令对设备进行访问, 并把设备的地址称作端口号. 有了端口号以后, 在I/O指令中给出端口号, 就知道要访问哪一个设备的哪一个寄存器了. 市场上的计算机绝大多数都是IBM PC兼容机, IBM PC兼容机对常见设备端口号的分配有. 设备中可能会有一些私有寄存器, 它们是由设备自己维护的, 它们没有端口号, CPU不能直接访问它们.

x86提供了in和out指令用于访问设备, 其中in指令用于将设备寄存器中的数据传输到CPU寄存器中, out指令用于将CPU寄存器中的数据传送到设备寄存器中. 一个例子是nexus-am/am/arch/x86-nemu/src/trm.c中serial_init()的代码, 代码使用out指令给串口发送命令字. 例如

movl $0x0, %al
movl $0x3f9, %edx
outb %al, (%dx)

上述代码把数据0x0传送到0x3f9号端口所对应的设备寄存器中. 你要注意区分I/O指令和命令字, I/O指令是CPU执行的, 作用是对设备寄存器进行读写; 而命令字是设备来执行的, 作用和设备相关, 由设备来解释和执行. CPU执行上述代码后, 会将0x0这个数据传送到串口的一个寄存器中, 串口接收到0x0后, 把它解释成一条命令, 发现是一条关中断命令, 于是就会进入关中断状态; 但对CPU来说, 它并不关心0x0的含义, 只会老老实实地把0x0传送到0x3f9号端口. 至于设备接收到0x0之后会做什么, 那就是设备自己的事情了. 事实上, 设备的行为都会在相应的文档里面有清晰的定义, 驱动开发者需要阅读设备的相关文档, 编写相应的命令字序列来对设备进行期望的操作. 在PA中我们无需了解这些细节, 只需要知道, 我们可以通过阅读相关文档, 编写相应的程序在CPU上运行来操作设备即可.

端口映射I/O把端口号作为I/O指令的一部分, 这种方法很简单, 但同时也是它最大的缺点. 指令集为了兼容已经开发的程序, 是只能添加但不能修改的. 这意味着, 端口映射I/O所能访问的I/O地址空间的大小, 在设计I/O指令的那一刻就已经决定下来了. 所谓I/O地址空间, 其实就是所有能访问的设备的地址的集合. 随着设备越来越多, 功能也越来越复杂, I/O地址空间有限的端口映射I/O已经逐渐不能满足需求了. 有的设备需要让CPU访问一段较大的连续存储空间, 如VGA的显存, 24色加上Alpha通道的1024x768分辨率的显存就需要3MB的编址范围. 于是内存映射I/O(memory-mapped I/O)应运而生.

内存映射I/O这种编址方式非常巧妙, 它是通过不同的物理内存地址给设备编址的. 这种编址方式将一部分物理内存"重定向"到I/O地址空间中, CPU尝试访问这部分物理内存的时候, 实际上最终是访问了相应的I/O设备, CPU却浑然不知. 这样以后, CPU就可以通过普通的访存指令来访问设备. 这也是内存映射I/O得天独厚的好处: 物理内存的地址空间和CPU的位宽都会不断增长, 内存映射I/O从来不需要担心I/O地址空间耗尽的问题. 从原理上来说, 内存映射I/O唯一的缺点就是, CPU无法通过正常渠道直接访问那些被映射到I/O地址空间的物理内存了. 但随着计算机的发展, 内存映射I/O的唯一缺点已经越来越不明显了: 现代计算机都已经是64位计算机, 物理地址线都有48根, 这意味着物理地址空间有256TB这么大, 从里面划出3MB的地址空间给显存, 根本就是不痛不痒. 正因为如此, 内存映射I/O成为了现代计算机主流的I/O编址方式: RISC架构只提供内存映射I/O的编址方式, 而PCI-e, 网卡, x86的APIC等主流设备, 都支持通过内存映射I/O来访问.

内存映射I/O的一个例子是NEMU中的物理地址区间[0x40000, 0x80000). 这段物理地址区间被映射到VGA内部的显存, 读写这段物理地址区间就相当于对读写VGA显存的数据. 例如

memset((void *)0x40000, 0, SCR_SIZE);

会将显存中一个屏幕大小的数据清零, 即往整个屏幕写入黑色像素, 作用相当于清屏. 可以看到, 内存映射I/O的编程模型和普通的编程完全一样: 程序员可以直接把I/O设备当做内存来访问. 这一特性也是深受驱动开发者的喜爱.

加入IOE

NEMU框架代码中已经提供了设备的代码, 位于nemu/src/device目录下. 代码提供了以下模块的模拟:

端口映射I/O和内存映射I/O两种I/O编址方式
串口, 时钟, 键盘, VGA四种设备

为了简化实现, 所有设备都是不可编程的, 只实现了在NEMU中用到的功能. 我们对代码稍作解释.

nemu/src/device/io/port-io.c是对端口I/O的模拟.
其中PIO_t结构用于记录一个端口I/O映射的关系,
设备会初始化时会调用add_pio_map()函数来注册一个端口I/O映射关系, 返回该映射关系的I/O空间首地址.
pio_read()和pio_write()是面向CPU的端口I/O读写接口.
由于NEMU是单线程程序, 因此只能串行模拟整个计算机系统的工作,
每次进行I/O读写的时候, 才会调用设备提供的回调函数(callback), 更新设备的状态.
内存映射I/O的模拟和端口I/O的模拟比较相似, 只是内存映射I/O的读写并不是面向CPU的, 这一点会在下文进行说明.
nemu/src/device/device.c含有和SDL库相关的代码, NEMU使用SDL库来模拟计算机的标准输入输出.
init_device()函数首先对以上四个设备进行初始化,
其中在初始化VGA时还会进行一些和SDL相关的初始化工作, 包括创建窗口, 设置显示模式等.
最后还会注册一个100Hz的定时器, 每隔0.01秒就会调用一次device_update()函数.
device_update()函数主要进行一些设备的模拟操作, 包括以50Hz的频率刷新屏幕,
以及检测是否有按键按下/释放.
需要说明的是, 代码中注册的定时器是虚拟定时器, 它只会在NEMU处于用户态的时候进行计时:
如果NEMU在ui_mainloop()中等待用户输入, 定时器将不会计时;
如果NEMU进行大量的输出, 定时器的计时将会变得缓慢.
因此除非你在进行调试, 否则尽量避免大量输出的情况, 从而影响定时器的工作.

我们提供的代码是模块化的, 要在NEMU中加入IOE, 你只需要在原来的代码上作少量改动: 在nemu/include/common.h中定义宏HAS_IOE. 定义后, init_device()函数会对设备进行初始化. 重新编译后, 你会看到运行NEMU时会弹出一个新窗口, 用于显示VGA的输出(见下文).

另一方面, 我们还需要在AM中实现相应的API为程序提供IOE的抽象 (在nexus-am/am/arch/x86-nemu/src/ioe.c中定义):

unsigned long _uptime()用于返回系统启动后经过的毫秒数
int _read_key()用于返回按键的键盘码, 若无按键, 则返回_KEY_NONE
_Screen _screen结构用于指示屏幕的大小
void _draw_rect(const uint32_t *pixels, int x, int y, int w, int h)用于
将pixels指定的矩形像素绘制到屏幕中以(x, y)和(x+w, y+h)两点连线为对角线的矩形区域
void _draw_sync()用于将之前的绘制内容同步到屏幕上
(在NEMU中绘制内容总是会同步到屏幕上, 因而无需实现此API)
void _ioe_init()用于进行IOE相关的初始化工作, 调用后程序才能正确使用上述IOE相关的API

下面我们来逐一介绍如何在AM中添加IOE的功能来支撑程序的运行.

串口

串口是最简单的输出设备. nemu/src/device/serial.c模拟了串口的功能. 其大部分功能也被简化, 只保留了数据寄存器和状态寄存器. 串口初始化时会注册0x3F8处长度为8个字节的端口作为其寄存器, 但代码中只模拟了其中的两个寄存器的功能. 由于NEMU串行模拟计算机系统的工作, 串口的状态寄存器可以一直处于空闲状态; 每当CPU往数据寄存器中写入数据时, 串口会将数据传送到主机的标准输出.

事实上, 我们之前提到的_putc()函数, 就是通过串口输出的. 然而AM却把_putc()放在TRM, 而不是IOE中, 这让人觉得有点奇怪. 的确, 可计算理论中提出的最原始的TRM并不包含输出的能力, 但对于一个现实的计算机系统来说, 输出是一个最基本的功能, 没有输出, 用户甚至无法知道程序具体在做什么. 因此在AM中, _putc()的加入让TRM具有输出字符的能力, 被扩充后的TRM更靠近一个实用的机器, 而不再是只会计算的数学模型.

nexus-am/am/arch/x86-nemu/src/trm.c中已经提供了串口的功能. 为了让程序使用串口进行输出, 你还需要在NEMU中实现端口映射I/O.

时钟

有了时钟, 程序才可以提供时间相关的体验, 例如游戏的帧率, 程序的快慢等. nemu/src/device/timer.c模拟了i8253计时器的功能. 计时器的大部分功能都被简化, 只保留了"发起时钟中断"的功能(目前我们不会用到). 同时添加了一个自定义的RTC(Real Time Clock), 初始化时将会注册0x48处的端口作为RTC寄存器, CPU可以通过I/O指令访问这一寄存器, 获得当前时间(单位是ms).

键盘

键盘是最基本的输入设备. 一般键盘的工作方式如下: 当按下一个键的时候, 键盘将会发送该键的通码(make code); 当释放一个键的时候, 键盘将会发送该键的断码(break code). nemu/src/device/keyboard.c模拟了i8042通用设备接口芯片的功能. 其大部分功能也被简化, 只保留了键盘接口. i8042初始化时会注册0x60处的端口作为数据寄存器, 注册0x64处的端口作为状态寄存器. 每当用户敲下/释放按键时, 将会把相应的键盘码放入数据寄存器, 同时把状态寄存器的标志设置为1, 表示有按键事件发生. CPU可以通过端口I/O访问这些寄存器, 获得键盘码. 在AM中, 我们约定通码的值为断码 + 0x8000.

VGA

有兴趣折腾的同学可以尝试在NEMU中运行litenes(在nexus-am/apps/litenes目录下). 没错, 我们在PA1的开头给大家介绍的红白机模拟器, 现在也已经可以在NEMU中运行起来了!

事实上, 我们已经实现了一个冯诺依曼计算机系统! 你已经在导论课上学习到, 冯诺依曼计算机系统由5个部件组成: 运算器, 控制器, 存储器, 输入设备和输出设备. 何况这些咋听之下让人云里雾里的名词, 现在都已经跃然"码"上: 你已经在NEMU中把它们都实现了! 再回过头来审视这一既简单又复杂的计算机系统: 说它简单, 它只不过在TRM的基础上添加了IOE, 本质上还是"取指->译码->执行"的工作方式, 甚至只要具备一些数字电路的知识就可以理解构建计算机的可能性; 说它复杂, 它却已经足够强大来支撑这么多酷炫的程序, 实在是让人激动不已啊! 那些看似简单但又可以折射出无限可能的事物, 其中承载的美妙规律容易使人们为之陶醉, 为之折服. 计算机, 就是其中之一.

你需要在实验报告中用自己的语言, 尽可能详细地回答下列问题.

编译与链接
在nemu/include/cpu/rtl.h中, 你会看到由static inline开头定义的各种RTL指令函数.
选择其中一个函数, 分别尝试去掉static, 去掉inline或去掉两者, 然后重新进行编译, 你会看到发生错误.
请分别解释为什么会发生这些错误? 你有办法证明你的想法吗?
编译与链接
1. 在nemu/include/common.h中添加一行volatile static int dummy; 然后重新编译NEMU.
  请问重新编译后的NEMU含有多少个dummy变量的实体? 你是如何得到这个结果的?
2. 添加上题中的代码后, 再在nemu/include/debug.h中添加一行volatile static int dummy; 然后重新编译NEMU.
  请问此时的NEMU含有多少个dummy变量的实体? 与上题中dummy变量实体数目进行比较, 并解释本题的结果.
3. 修改添加的代码, 为两处dummy变量进行初始化:volatile static int dummy = 0; 然后重新编译NEMU.
  你发现了什么问题? 为什么之前没有出现这样的问题? (回答完本题后可以删除添加的代码.)
了解Makefile
请描述你在nemu目录下敲入make 后, make程序如何组织.c和.h文件, 最终生成可执行文件nemu/build/nemu.
(这个问题包括两个方面:Makefile的工作方式和编译链接的过程.)
关于Makefile工作方式的提示:
- Makefile中使用了变量, 包含文件等特性
- Makefile运用并重写了一些implicit rules
- 在man make中搜索-n选项, 也许会对你有帮助
- RTFM

Previous基础设施(2)NextPA3 - 穿越时空的旅程: 异常控制流