一个示例123456asm volatile( "jalr x0, 0(%0)" : : "r"(jump_address) : ); 代码片段的格式和含义分解： 这段代码使用了 GCC 扩展内联汇编的通用格式，其基本结构如下： 123456asm [volatile] ( 汇编指令模板 : //

前言docker 在 pull 镜像的时候，速度要么很慢，要么直接卡住报错，这是因为网络不通的原因。主要有两个思路，方案一就是换源，将 docker 的仓库换到镜像源上，因为镜像源在国内，因此这种方式便宜。但缺点是镜像可能会在某个时间节点停止服务，不够稳定。方案二就是不用管源的事情，直接在本地架设代理，缺点是技术门槛高，需要架设代理，还需要支付额外的流量费。优点是源不会挂掉，很稳定。 方案一创

2023 年的目标“因此在 2024 年，我将会学习更多的关于算法（CS61B）、计算机网络（CS114）、 数据库、编译原理、Java（面向实习学习）、分布式等知识，争取能在暑假拿到offer。” 上述言论是我在 2023年12月31 在博客中提到的。当时我的想法是学习 Java 后端，学习通用的 Java 学习路线，然后在暑假拿到 实习offer。 但最终，2024 年一整年，我的学习内容

前言阅读本案例需要有做 nemu 的经历，最低要求是是做到 PA3.1。 一个最简单的异常处理程序12345678910111213141516#include <klib.h>void handler() { uintptr_t mepc; asm volatile("csrr %0, mepc" : "=r"(mep

前言思路1、将默认信号改成握手信号2、加上随机延迟3、综合测试 状态机的角度进行思考，如何进行状态转换，这个过程中，要考虑信号延迟，因此要能将状态能够保持几个周期，因此要在信号发射端，保持这些信号。总之，谁发射，谁负责，谁接收到了，谁转换状态。 CPU 的状态完全靠寄存器来保持；MEM 的状态完全靠寄存器来保持。

前言AXI（Advanced eXtensible Interface）是 AMBA（Advanced Microcontroller Bus Architecture）协议家族的一部分，由 ARM 公司制定。AXI 是一种高性能、可扩展的总线协议，广泛用于 SoC（System on Chip） 设计中，特别适用于高带宽、低延迟的应用。它主要用于在系统中不同组件之间传输数据和控制信号，尤其是

前言前面谈到了异常响应机制，如果在上下文恢复的时候，做点手脚，比如别让它回到原来的上下文，而是回到了另一个进程的上下文，那么这就是进程切换，也是多道程序的基础。 yield OS前言就是 yield OS 的核心思想了，实现kcontext 后，别忘了修改 trap.S，使得 a0 这个返回值传到 sp。 1234567Context* kcontext(Area kstack, void (

前言在 riscv 中，当发生异常的时候，需要调用 ecall 指令来陷入异常: 12345678910111213#define ECALL(dnpc) \ {

前言在把 PA2.3 做完之后，顺手把 ysyx 的 npc 中的设备模仿 nemu 也实现了一下，分别是串口、时钟、vga，本文讨论一下这三种设备的区别。事实上，这三种设备循序渐进，虽然是三种设备，但其实在 CPU 眼里，它就是同一种东西，都是读写内存。 设备在 nemu 的模型中，程序访问设备的时候，会提供统一的接口，比如 io_read、io_write，比如： 123456789101

前言昨天开组会，助教在会上问了一个问题：A 函数调用 B 函数，s0 的保存是哪一个函数进行的。我觉得这个问题挺熟悉的，因为之前在看 riscv 的 xv6 操作系统时遇到过。 实验main.c: 12345678#include <add.h>#include <stdio.h>int main() { int a = 10, b = 5; in