最近看到ESI那个"永恒计算机"项目，说30行伪代码的单指令虚拟机能让今天的软件千年后还跑得动。我第一反应不是激动，是想起工地上那些"一劳永逸"的漂亮设计。图纸看起来极简，但维修成本全甩给了后面接手的师傅。
从某种角度看，把执行层压到极限确实优雅，好像降低了被技术迭代淘汰的风险。但单指令集把内存管理、IO、并发这些现代抽象层全扔了，等于把未来维护者一脚踹回裸计算世界。千年后的开发者要让你的代码跑起来，得先逆向重建整个执行范式。这不像保存遗产，更像把遗产变成一座需要不断破译的考古谜题。
我在夜校写代码不多，但给工地画过施工图。能让图纸十年后还管用的，从来不是线条少，而是图例、标高、材料说明都写清楚。软件遗产也一个道理，可执行性只是底线，"可理解性封装"才是核心。与其赌未来有人愿意复现那30行伪代码，不如现在把RISC-V二进制配上语义注释和形式化规格，让后人不仅跑得了，还能读得懂、改得动。
最靠谱的方舟，往往不是最小的那艘，而是零件最容易找到的那艘。
OISC本质是把编译期复杂度甩给运行时，debug体验约等于查无符号表的core dump。你的施工图类比很准，存档瓶颈从来不在ISA，而在toolchain的确定性。
跨周期维护建议直接上三层快照：
qemu-system-riscv64 全量镜像固化HAL之前在深圳做项目时为了追求极简架构砍了注释，后期重构成本直接指数级上升。抗熵增靠的不是行数少，是上下文完整。
你跑归档测试时更倾向存IR还是直接封二进制？
单指令集剥离现代抽象层确实会抬高逆向门槛，但从数字保存（digital preservation）的实证数据来看，真正的断裂点往往不在这儿。2019年一项针对早期开源项目存档的追踪显示，导致代码不可复现的首要因素并非硬件淘汰，而是隐式依赖库的腐烂，占比超过68%。极简执行环境恰恰是在做减法，主动切断那些会随时间指数级衰减的dependency tree。
值得商榷的是，形式化规格的长期维护成本经常被低估。ISO 14721（OAIS模型）早就指出，长期可读性依赖的是“信息包+渲染环境”的双轨制。你提的RISC-V配语义注释是个扎实的路径，但或许可以补充一个分层策略：把那30行伪代码固定为最底层的reference VM，上层用标准化元数据（如PREMIS schema）封装运行时的内存映射与I/O假设。这样后人不需要考古式破译，只需对照context manifest就能重建当时的执行范式。
把最小执行核和完整语义层拆开维护，可能比追求大一统的封装更抗老化。跑legacy test suite的时候，要不要试试把依赖图和元数据分开导出对照看看？