硬件、软件接口

1. 一行 C 代码，凭什么能点亮一盏灯

嵌入式里最让人"上头"的一行代码，大概是这样的：

*((volatile unsigned *)0x10012000) = 1;   // 把 GPIO 某个引脚置 1，灯就亮了

从语法看，它无非是"往一个地址写 1"。可那个地址上既没变量、也没内存，而是一颗 LED 的引脚寄存器。为什么一行赋值就能让物理世界的灯亮？

答案藏在一个核心事实里：软件和硬件之间，从来不是靠"魔法"对接，而是靠一份早就约定好的地址与规则——这份契约，就是本文的主题"硬件 / 软件接口"。

本质一句话：软件能指挥硬件，是因为有人把"硬件的开关"映射成了软件能访问的"地址"，并规定了访问它的规矩。

2. ISA：软硬件之间的第一份契约

最底层的接口是指令集架构（ISA，Instruction Set Architecture）。它是 CPU 设计者和编译器作者之间的一份"互不入侵"的契约：

• 对软件（编译器 / 操作系统）而言：只要我产生的指令是 RISC-V（或 x86）的，并且遵守寄存器约定、特权级规则，你的 CPU 就必须正确执行——至于你内部用几级流水线、乱序还是顺序、有没有分支预测，软件一概不关心。
• 对硬件（CPU）而言：只要送来的指令合法，你就得按手册给出结果——软件怎么优化、跑在哪个操作系统上，硬件也不关心。

正是这份契约，让你写的 C 程序能"一次编译、四处运行"：换一颗同 ISA 的 CPU，上层软件一行不改。这层契约也叫 ABI 的上游边界。

但 ISA 只解决了"指令怎么执行"。还有一个更日常的问题：软件怎么和数据、和"外面的世界"打交道？这就轮到另一个接口登场——内存映射 I/O。

3. 内存映射 I/O：设备寄存器也是"内存地址"

计算机里"内存"和"设备"在硬件上是两套东西：内存是 RAM，设备是 UART、磁盘控制器、GPU。但 RISC-V、ARM 这些架构选择了一个统一的做法——内存映射 I/O（MMIO，Memory-Mapped I/O）：把设备的寄存器，直接挂在 CPU 的地址总线上，分配一段普通地址。

于是 CPU 不需要专门的 in / out 指令，用和访问内存一模一样的 load / store 就能读写设备。地址译码器看地址落在哪一段，决定把这次访问送给 RAM 还是送给设备寄存器。

关键点：MMIO 区域的访问是不可缓存的（uncached）。因为"读设备"是有副作用的——读一次状态寄存器，设备可能就把"已读"标志清掉了；如果 CPU 把它缓存起来，下次就不去真总线上读了，驱动就会读到过时的假数据。这也正是后面 volatile 坑的根源。

4. 一次轮询读的完整握手（含可运行代码）

光讲概念太空。下面用一个纯用户态、可直接编译运行的小程序，模拟"驱动通过总线访问 UART 寄存器"的全过程——它把"硬件"也用软件假装了出来，所以你能在本机把它跑通看输出。

/* bus.c —— 用一段用户态程序模拟「CPU 通过总线访问 MMIO 设备寄存器」
 * 编译：gcc -O2 -std=c11 -Wall -o bus bus.c
 * 运行：./bus
 */
#include <stdio.h>
#include <stdint.h>
#include <string.h>

/* ---------- 下面是「硬件」：一条只有 64 字节的地址空间 ---------- */

#define UART_SR      0x10        /* 状态寄存器：bit0 = RX 就绪 */
#define UART_DR      0x14        /* 数据寄存器：读=收一字节，写=发一字节 */
#define DEV_LATENCY  3           /* 模拟慢设备：每查 3 次状态才送出 1 字节 */

static const char *hw_fifo = "RISC-V";   /* 设备侧已经收到的数据 */
static size_t      hw_pos  = 0;
static int         sr_queries = 0;       /* 统计状态寄存器被读了多少次 */

static uint32_t bus_load(uint32_t addr)
{
    switch (addr) {
    case UART_SR:
        sr_queries++;
        if (hw_pos < strlen(hw_fifo) && sr_queries % DEV_LATENCY == 0)
            return 1u;                    /* RX 就绪 */
        return 0u;                        /* 还没好 */
    case UART_DR:
        if (hw_pos < strlen(hw_fifo))
            return (unsigned char)hw_fifo[hw_pos++];
        return 0u;
    default:
        return 0xFFFFFFFFu;               /* 真实硬件上这叫「总线错误」 */
    }
}

static void bus_store(uint32_t addr, uint32_t val)
{
    if (addr == UART_DR)
        printf("  [TX] 发送字节 '%c'\n", (char)(unsigned char)val);
    else
        printf("  [bus] 写 0x%02X <- 0x%08X：无设备响应\n", addr, val);
}

/* ---------- 上面是硬件的边界，下面是软件（驱动） ---------- */

static char uart_getc(void)
{
    int spins = 0;
    while ((bus_load(UART_SR) & 1u) == 0)    /* 轮询：直到 bit0 为 1 */
        spins++;
    char c = (char)bus_load(UART_DR);
    printf("[驱动] 收到 '%c'（空转查询 %d 次）\n", c, spins);
    return c;
}

static void uart_putc(char c) { bus_store(UART_DR, (unsigned char)c); }

int main(void)
{
    printf("驱动开始轮询 UART_SR(0x%02X)，等待 RX 就绪\n", UART_SR);
    char frame[7];
    for (int i = 0; i < 6; i++) frame[i] = uart_getc();
    frame[6] = '\0';
    printf("[驱动] 收到完整帧: \"%s\"\n", frame);
    printf("[驱动] 共查询状态寄存器 %d 次，收到 %d 字节\n", sr_queries, 6);
    uart_putc('O');
    uart_putc('K');
    bus_store(0x3C, 0x1);    /* 往一个没有设备的地址写，看会发生什么 */
    return 0;
}

真实输出（用等价转写在 Python 上跑过，逻辑与上面 C 完全一致）：

驱动开始轮询 UART_SR(0x10)，等待 RX 就绪
[驱动] 收到 'R'（空转查询 2 次）
[驱动] 收到 'I'（空转查询 2 次）
[驱动] 收到 'S'（空转查询 2 次）
[驱动] 收到 'C'（空转查询 2 次）
[驱动] 收到 '-'（空转查询 2 次）
[驱动] 收到 'V'（空转查询 2 次）
[驱动] 收到完整帧: "RISC-V"
[驱动] 共查询状态寄存器 18 次，收到 6 字节
  [TX] 发送字节 'O'
  [TX] 发送字节 'K'
  [bus] 写 0x3C <- 0x00000001：无设备响应

这段输出里藏着三个接口要点：

1. 驱动只认地址，不认硬件形状——uart_getc 从头到尾没碰过 hw_fifo 这种"设备内部状态"，它只通过 bus_load(UART_SR / UART_DR) 这两个固定地址和硬件对话。换一颗 UART 芯片，只要寄存器地址和语义不变，驱动一行不用改。
2. "空转查询 2 次"就是轮询的代价——慢设备没好之前，CPU 只能在 while 里白转。设备越快，空转越少（这与上一篇 I/O 的取舍是一体两面）。
3. 往没设备的地址写，不会崩，只是"没人理你"——真实硬件上这会被总线标记为错误事务；这里用返回 0xFFFFFFFF 和一条提示模拟了它。

一次读字节的时序长这样（驱动 ↔ 总线 ↔ 设备，时间向下推进）：

5. 坑：少了 volatile，轮询循环会被编译器删掉

你大概已经注意到第 1 节那行代码里有 volatile。它不是装饰，而是 MMIO 驱动的生命线。问题出在：编译器不知道 UART_SR 的内容会被"它管不着的某样东西"（硬件）改动。 在它眼里，循环里从没写过那个内存，于是 -O2 优化会理直气壮地把读操作提到循环外——结果就是死循环。

写法一（错）和写法二（对）的对比：

/* volatile.c —— 同一个轮询循环，加不加 volatile 的差别 */
#include <stdint.h>

#define UART_BASE 0x10000000u
typedef struct { uint32_t sr; uint32_t dr; } uart_t;

#define UART_BAD  ((uart_t *)UART_BASE)            /* 错：编译器以为内存不变 */
#define UART_OK   ((volatile uart_t *)UART_BASE)   /* 对：每次访问都真的访存 */

char read_byte_bad(void)
{
    while ((UART_BAD->sr & 1u) == 0) { }    /* -O2 下可能变成死循环 */
    return (char)UART_BAD->dr;
}

char read_byte_ok(void)
{
    while ((UART_OK->sr & 1u) == 0) { }     /* 每次都在循环里真的读一次 */
    return (char)UART_OK->dr;
}

x86-64、gcc -O2 下大致生成这样的汇编（示意，关键在 load 在不在循环里）：

; read_byte_bad：sr 被提到循环外，只 load 一次
read_byte_bad:
        mov     eax, DWORD PTR ds:0x10000000     ; 循环外只读一次！
.L2:
        test    al, 1
        je      .L2                              ; 永远在寄存器上打转 → 死循环
        mov     eax, DWORD PTR ds:0x10000004
        ret

; read_byte_ok：读留在循环内，每次迭代都真的访存
read_byte_ok:
.L5:
        mov     eax, DWORD PTR ds:0x10000000     ; 循环内，每次都读
        test    al, 1
        je      .L5
        mov     eax, DWORD PTR ds:0x10000004
        ret

一个 volatile，把"循环外一次读"改成了"循环内每次读"——对普通内存是性能损失，对设备寄存器却是正确性的底线。所以 MMIO 的结构体、状态/数据寄存器指针，一律要 volatile 限定。

C++ / Java 对照：两种语言的 volatile 含义并不相同，跨语言移植时最容易踩坑。

// Java 里没有"裸 MMIO"，但可以用 VarHandle 拿到最接近 C volatile 的「不重排访存」
import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;

public class MmioDemo {
    private static int status = 0;             // 模拟设备状态寄存器

    private static final VarHandle SR;
    static {
        try {
            SR = MethodHandles.lookup()
                    .findStaticVarHandle(MmioDemo.class, "status", int.class)
                    .withInvokeExactBehavior();
        } catch (ReflectiveOperationException e) {
            throw new ExceptionInInitializerError(e);
        }
    }

    /** 等价于 C 的 volatile 读：编译器不得把读优化掉，但不建立跨线程 happens-before */
    static int readStatusOpaque() { return (int) SR.getOpaque(); }

    /** 普通 Java volatile 读：可见性 + 禁止重排序，语义比 C 的 volatile 强得多 */
    static int readStatusVolatile() { return status; }

    static void waitReady() {
        while ((readStatusOpaque() & 1) == 0) { /* spin */ }
    }
}

两者的差别，一句话：C 的 volatile 只承诺"每次都真去访存"，对多线程几乎无保护作用；Java 的 volatile 在 JMM 下额外保证"可见性 + 禁止重排序"（happens-before），语义强得多，却仍然不保证 i++ 这种复合操作的原子性。 想做"设备级"的强语义访存，Java 得用 VarHandle 的 getOpaque / getAcquire 模式，而不是普通的 volatile 字段。

6. 特权级：为什么你的程序不能自己碰设备

MMIO 给了软件"读写设备"的能力，但现实里普通应用程序并不直接去 load 设备地址——否则任意程序都能读网卡、写磁盘控制器，系统就乱套了。于是 ISA 在"能不能碰设备"上又划了一条线：特权级（privilege level）。

以 RISC-V 为例，有 U（用户）/ S（监管）/ M（机器）三档；应用程序跑在 U-mode，执行特权指令或访问设备 MMIO 会被硬件拦截。要碰设备，必须经由系统调用 ecall 进入内核，由内核里的设备驱动代劳。这就形成了两层清晰的边界：

所以"应用 → 设备"的完整链路是：应用程序调 write(fd, buf, n) → libc 按 ABI 把参数塞进寄存器并 ecall → 内核里的 UART 驱动按 MMIO 协议 store 数据寄存器 → 硬件把字节推出去。应用从不直接接触硬件，它甚至不知道 UART 的地址是多少——这正是接口分层带来的安全与解耦。

7. 这条边界一直在移动

"什么该硬件做、什么该软件做"不是天经地义的，历史上反复横跳：

• 软件 → 硬件：早期浮点运算靠软件库模拟，后来有了 FPU 协处理器，再后来直接进 CPU；AES-NI、CRC32、RDTSC 这些原本要几十上百条指令算的，现在是一条硬件指令。方向是"高频且规整的操作下沉到硬件"。
• 硬件 → 软件：x86 的复杂指令其实大多靠内部微码（microcode）"用软件解释"，出 bug 能靠微码更新修；RISC 则干脆把复杂度推给编译器，CPU 更省晶体管。方向是"不规整、易变的逻辑留给软件"。
• CPU → 设备：DMA 把"搬数据"从 CPU 手里拿走交给控制器；GPU、NPU 把矩阵运算从通用核拿走。方向是"和主计算流解耦的活，让专用硬件干"。

判断该放哪一层，一句口诀："谁更知道自己在干嘛、谁更常变、谁能并行，就离硬件更近。"

8. 对比表与小结

接口	角色	谁守约	越界后果
ISA	指令怎么执行	CPU ↔ 编译器	换 ISA 上层全重编
MMIO	设备寄存器 = 地址	CPU 译码 ↔ 驱动	地址错 → 写飞 / 总线错误
volatile	迫使每次真访存	编译器	缺 → 轮询死循环
ABI / 系统调用	用户态 ↔ 内核态	libc ↔ 内核	参数约定错 → 内核 panic
特权级	谁能碰设备	硬件	用户态直访 → 非法指令异常

🐾 小结：

• 软件能指挥硬件，靠的不是魔法，而是"地址 + 规则"的契约：设备寄存器被映射成地址，CPU 用普通 load / store 访问。
• MMIO 区不可缓存、读有副作用——所以驱动里的寄存器指针必须 volatile，否则 -O2 会把轮询读提到循环外，变成死循环。
• 两层边界各管一件事：ABI 边界（换 CPU 不动上层）守"调用约定"，ISA / 特权级边界（换 OS 不动应用）守"能不能碰设备"。应用从不直接碰硬件，一律经系统调用交驱动代劳。
• C 的 volatile ≠ Java 的 volatile：前者只保证"真去访存"，后者还保"可见性 + 禁止重排序"，但都不保复合操作原子性。
• 软硬件边界是流动的：高频规整、能并行的操作下沉硬件；易变、不规整的逻辑留给软件。

相关阅读：上一篇《中断与 I/O》讲"轮询 / 中断 / DMA 三种等待方式"，本篇是它在"地址与特权"层面的接口补全。