static、inline1. static 关键字 作用：限制函数的作用域仅限于定义它的源文件（即内部链接）。这意味着每个包含该头文件的源文件都会生成该函数的一个独立实例，避免了多个定义导致的链接错误。 在头文件中使用：适用于小型、频繁调用的函数，允许每个源文件拥有自己的函数副本，避免链接器的重复定义错误。 2. inline 关键字 作用：建议编译器将函数调用替换为函数体本身，以减少函数

一、一个问题1234native 的 IOE 是基于 SDL 库实现的, 这些库很有可能会调用 glibc 的库函数, 例如 malloc()和 free(). 但我们自己实现的 klib 通常不能完美地符合 glibc 的标准, 因此直觉上看, 如果定义了__NATIVE_USE_KLIB__, 很可能会导致SDL库产生不正确的行为.不过会发现, 即使定义了__NATIVE_USE_KLIB

一、前言前文细致地研究了命令 make ARCH=native ALL=add run 的运行过程，对于Makefile中的行为有了很准确地把握（几乎没有疑点，可以随意修改 Makefile 且保证不会出错）。这篇文章继续研究命令make ARCH=riscv32-nemu ALL=add run的行为。 二、riscv32-nemu 开始的地方由于 ARCH=riscv32-nemu，因此

前言这里记录一下配置Ubuntu22.04的过程，主要实现了： ssh 远程免密访问 配置 git & github 内网穿透远程 ssh 访问 v2ray、v2raya(虽然最后采用了其它的网络加速方案，但也是可行的) zsh 美化 远程桌面访问（目前只能在同一局域网下，内网穿透失效） 换软件源 开机启动脚本 hexo & npm ssh 远程免密访问因为这台电脑的角色是

一、前言现在做到了 PA2.3后面，遇到的问题有点多，感觉总在棉花上踩。遇到了一个 bug 迟迟无法解决：用 native 且没有定义 __NATIVE_USE_KLIB__ 跑 Bad Apples 会失败，但是用 nemu 跑竟然会成功。这说明我的 klib 比 glibc 还完备吗？看了两个小时，也没看出什么。思考良久，感觉还是对项目构建过程缺乏细节上的了解，这成了学习进度上的瓶颈。于是

〇、前言为什么这一年还没结束，就要总结一些事情呢？因为今天是大三开学的第一天，也是今天我今天来学校的第一天。这里讲一个小故事，今天下午 4 点 30 我准时来到学校，也就意味着我没有参与上午的课。尽管这样，我心中还是很窃喜。我原本打算昨天来到学校，这样我就能参与今天的课。但是昨天的温度很高，我上午看了一下天气预报，实时温度是 39 度。但是我认为绝对不仅仅是 39 度，真实室外温度可能超过 4

nemu首先研究 nemu 的构建方式。 直接看 nemu 的 Makefile(~/ysyx-workbench/nemu/Makefile): 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859

运行时环境一个事实是, 应用程序的运行都需要运行时环境的支持, 包括加载, 销毁程序, 以及提供程序运行时的各种动态链接库(你经常使用的库函数就是运行时环境提供的)等. 为了让客户程序在NEMU中运行, 现在轮到你来提供相应的运行时环境的支持了。 程序的运行时环境（Runtime Environment）是指在程序执行时提供的软件和硬件环境，它支持程序的运行并提供必要的服务和资源。运行时环境通常包

前言上一篇博客中介绍了如何添加指令，这篇将会熟悉这个过程，学习以及添加更多的指令。 所有程序在am-kernels/tests/cpu-tests/tests 目录下有很多测试： 12345678910111213141516171819202122232425262728293031323334353637ls -ltotal 140-rw-rw-r-- 1 l

前言前面讨论了 nemu 执行一条指令的过程，在源码中，可以看到它目前可以解析的指令有限： 1234567891011121314151617181920212223242526272829static int decode_exec(Decode* s) { int rd = 0; word_t src1 = 0, src2 = 0, imm = 0; s->