〇、前言前两篇分别讲了 GitHub 权限分层和几种 token 的身份模型。 这一篇把它们落到一个完整的自动发布场景里： 1234example-org/web-client→ GitHub Actions 构建资源→ 发布到 example-org/resource-assets→ 用户或程序下载 release asset 这条链路看起来只是一个普通 CI/CD： 1push m

〇、前言上一篇主要讲了 GitHub 的权限不是一句“我是 member”能解释的。它至少要看用户、组织、团队、仓库、分支保护、rulesets 等多层关系。 这一篇进入自动化里最容易混乱的部分：token。 在 GitHub 里，我们经常会看到很多种 token： Classic PAT； fine-grained PAT； GITHUB_TOKEN； GitHub App installat

〇、前言我以前看 GitHub 权限的时候，总觉得它应该很简单： 我是不是这个组织的 member？我是不是这个仓库的 admin？我能不能 push？ 后来真正把 GitHub Actions、跨仓库 release、PAT、GitHub App 放到一起用的时候，才发现这个理解太粗了。 GitHub 的安全模型不是一层，而是很多层叠在一起。一个人可能是 organization 的 mem

前言前面几篇已经把链路铺完整：LLVM 后端能发，MC 层能编码，模拟器能作为 reference model，AM/BSP 能承载裸机程序，RTL 评测也有了控制变量。现在可以讨论结果，但仍然要保持克制。 更准确的总结是： 123RISC-VI 在当前同源双发射 RTL 功能模型中，通常能减少动态提交数和部分短依赖，但也会暴露三源读端口、load-use 和分支预测口径上的真实代价。

前言做 ISA 研究，最容易把话说过头。看到动态指令数少了，就说性能更好；看到某个程序周期少了，就说 ISA 更快；看到分支错误少了，就说分支预测改善了。这些说法如果没有控制变量，很容易误导。 RISC-VI 项目里专门冻结了一份 RTL 评测口径。它的核心原则可以概括成一句话： 12所有“RISC-VI 比 RV32R 更好”的结论，都必须建立在同前端、同预测器、同 LSU、同 memory、同

前言LLVM 后端能生成汇编，模拟器能执行指令，这还不足以支撑系统实验。因为真实的 C 程序不是从 main() 自己冒出来的，它需要启动代码、栈、.bss、链接脚本、平台 I/O 和停机约定。 AM/BSP 最小运行时解决的就是这个问题：让 C 程序以裸机 workload 的形式进入模拟器和 RTL。 裸机程序为什么不能直接从 main() 开始在普通操作系统里，用户程序

前言ISA 实验必须有一个真值源。否则 LLVM 发出一条新指令后，很难判断错误来自哪里：是后端 pattern 选错了、MC 编码错了、模拟器语义错了，还是 RTL 实现错了。 RISC-VI 项目里的 C 模拟器承担的不是“跑个 demo”的角色，而是 reference model： 它定义 RV32R 和 RISC-VI32R 的提交级 ISA 语义。 它把程序运行结果变成结构化 JSO

前言ISA 设计最怕变成“我觉得这条指令有用”。RISC-VI 的做法是反过来：先看 LLVM 生成的 RV32I 汇编到底暴露了哪些瓶颈，再从瓶颈里推导指令。 这种方法的重点不是跑几个命令，而是建立一条证据链： 123456C workload -> LLVM 生成 RV32I 汇编 -> 静态指令和依赖分析 -> 双发射压力分类 -> 候选 ISA 模式 -&

前言很多人第一次做 ISA 扩展，会以为“加一条指令”就是在模拟器里写一个 case，或者在 LLVM 里写一个 TableGen def。真正的工程现实要复杂得多。 一条指令要成为系统里稳定存在的能力，至少要被这些层同时认识： LLVM feature 和 predicate； TableGen 指令编码、操作数和属性； 指令选择 pattern 或 C++ selector； MC 汇编器和

前言定义机器指令只是第一步。LLVM 后端真正有趣的问题是：它什么时候会主动生成这些指令？ 这不是字符串替换。LLVM 不会看到汇编里有 slli; add; lw 再粗暴改成 lwxs。更真实的路径是： 1234567LLVM IR -> DAG combine / legalize -> SelectionDAG 节点 -> target-specific addres