调研窗口：2026-10-30 05:00 ~ 2026-11-02 05:00（北京时间，72 小时，覆盖周末）。

信源：Google News 聚合（中英文 27 组查询，走代理）、Hacker News、Phoronix、CNX Software、LinuxGizmos、LWN、riscv.org 官方博客、openRuyi 官网新闻页与主仓、RISC-V 国际基金会会员企业官网巡检（391 家）、riscv100.top 榜单巡检，以及 GitHub 上香山 XiangShan／NEMU／difftest／XSCache／GEM5、CORE-V CVW／CVA6、达摩院玄铁、奕斯伟、算能、芯来、乐鑫、进迭时空与 spacemit-robotics、矽速、revyos、openRuyi-Project、Radxa Linkr 等组织与重点仓库的提交与发布检索。

本期索引

  • 今日重点：Linux 7.4 把「快非对齐访问」改为运行期探测，发行版内核可吃到最多 11% 带宽收益（10-30）
  • RISC-V 100 榜单动态
    • 榜单新增 10-17 记录：XSCC 2.0 on 香山 KMHv3 RTL 3GHz，int 68.41、fp 76.95（11-02 巡检）
    • 两条旧记录下榜：LLVM 22.1.0 on 进迭 K3 X100、XSCC 1.1 on 知合 A210 C908（11-02 巡检）
  • 一、开源社区与软件生态
    • 香山前端引入 FtqPrefetchQueue，iprefetch 重构第一步（10-30）
    • 香山修 MBTB 对隐藏 VBTB 分支的分配抑制（10-30）
    • 香山把 prefetch.i/r/w 解码为 LSU 预取操作（10-30）
    • 香山 CI 性能流启用 lightSSS，GEM5 周测切到 261013 配置（10-30）
    • difftest 两天九笔：MMA 后端把 FP8 乘积打包进 cache word（10-30 至 11-01）
    • NEMU 为 AME 补 replay 状态回滚，修 hosttlb 矩阵寄存器选择符（10-30、10-31）
    • XSCache 修 CoupledL2 另一路 hint 被持续阻塞（10-30）
    • openRuyi 引入 llvm23 23.1.4，riscv64-openruyi-linux 默认 RVA23U64（10-30）
    • CORE-V CVW 按 Svvptc 不再缓存无效 PTE（10-30）
    • CORE-V CVW 修 trace 的 VM 字段与 quad 溢出检测，rv64gc 覆盖率达 100%（10-30）
  • 二、产品与生态动态
    • Qwenputer 把 RV32IM 编译进 Qwen3.5-4B 权重，用注意力状态当 RAM（10-30）
    • 进迭时空建 Bianbu AgentOS 伞仓，端侧 agent 栈按子模块锁定（10-30）
    • 进迭时空 docs-chip 移除 P1S 文档，docs-product 更新 K3 Pico 资源链接（10-30）
    • Radxa Linkr 增 OBS 浏览器采集指南，初始化 linkr-now-skill（10-30）
  • 三、国内团队深挖
    • 芯来发布 Nuclei Studio VS Code IDE 预览版，工具指南同步到 2026.10（10-30）
    • 算能 LLM-TPU 支持 InternVL3／LLaMa3，修 Qwen3-ASR 解码退化（10-30）
    • 达摩院玄铁与奕斯伟窗口内组织级零新开发（11-02）
  • 四、具身智能与机器人专章
    • 进迭时空新增统一机械臂控制框架，85 文件落标定／诊断／运动学（10-30）
    • 进迭时空 dice_arena 加入集成骰子游戏应用（10-30）
    • 进迭时空 docs-ros 补英文 RealSense 指南，对齐中英文档（10-30）
  • 五、总结与趋势观察
  • 附录：完整信源清单与信源核查表

今日重点：Linux 7.4 把「快非对齐访问」改为运行期探测，发行版内核可吃到最多 11% 带宽收益（10-30）

Linux 7.4 的 RISC-V 架构改动已并入主线，其中一条优化值得单独记：跳过软件对齐的判定从编译期挪到了运行期。

这条优化的来路分两步。Linux 7.3 由 Tenstorrent 提交的改动，让「为支持快速非对齐内存复制的 RISC-V 硬件编译的内核」跳过软件对齐，Tenstorrent 自测带宽提升最高 11%。但 7.3 要求该能力在编译时打开，而一个发行版内核要服务一批硬件，其中总有慢速非对齐访问的芯片，于是这条收益只能留在定制内核里，通用构建吃不到。7.4 把判定改挂到 HAVE_EFFICIENT_UNALIGNED_ACCESS 上做运行期探测：只有探测到硬件确实支持快速非对齐访问，用户态拷贝才跳过软件对齐。这样一来，发行版 RISC-V 内核与其它通用构建都能默认带上这条优化，而不必为老硬件保留一份特制镜像。

同批并入 7.4 的 RISC-V 改动还有：crash 热插拔支持、部分页表函数走优化路径、上下文切换的一处优化、「B」扩展进入 hwcap 与 hwprobe 上报，以及 Zic64b 扩展的上报支持。这几条单看都不大，但合起来是「内核把 RISC-V 平台能力摸清并交给自己调度」的一步——尤其是 hwprobe 侧的上报，正是运行期探测这类优化的前提。

社区讨论里有一个值得记录的判断：Hacker News 上有读者问快速非对齐访问是否只属服务器 CPU，回复指出除 SiFive 外几乎各家都支持，SiFive 只在新一代性能核上支持。这提示发行版打开这条优化后，实际受益面取决于芯片是否在 hwprobe 里如实上报，而不是取决于产品定位。

日期：2026-10-30　来源：Phoronix：RISC-V Has A Nice Portable Performance Optimization With Linux 7.4、Hacker News 讨论

RISC-V 100 榜单动态

本期巡检（跨过周末，距上次 10-28 巡检四天）发现榜单有实质变化，按用户口径置于正文靠前。

榜单新增（跨架构 · SPEC CPU2006 与 RISC-V 频道 · SPEC CPU2006 各一条）：10-17｜香山编译器团队（XSCC）｜XSCC 2.0 on 香山 KMHv3 RTL 3GHz｜int 68.41、fp 76.95（speed/ref，Completed）；较同编译器上一记录（10-15，XSCC 2.0）int +0.8%、fp +0.5%。这条记录的日期是 10-17，早于本次巡检日，属补录上榜——10-28 巡检时两张 CPU2006 榜的榜首还是 10-15 的 int 67.85、fp 76.54。

下榜两条：跨架构 · SPEC CPU2006 的 07-27 记录「LLVM 22.1.0 on 进迭 K3 X100 2.4GHz」下榜；RISC-V 频道 · SPEC CPU2006 的 08-05 记录「XSCC 1.1 on 知合 A210 C908 1.9GHz」下榜。两处下榜与一条补录同时发生，更像榜面整理而非新测量——同编译器口径下 +0.8%／+0.5% 的差异也在噪声量级，不宜单独解读为架构改进。

日期：2026-11-02　来源：riscv100.top 跨架构 SPEC CPU2006 榜、riscv100.top RISC-V 频道 SPEC CPU2006 榜

一、开源社区与软件生态

香山前端引入 FtqPrefetchQueue，iprefetch 重构第一步（10-30）

第 6691 号是香山前端本轮最重的一笔，16 个文件、+471/−198。改动核心是新增 FtqPrefetchQueue，把取指预取从 ICache-top 上收到 FTQ 侧统一调度。

原设计的三个问题写得很直白。其一，FTQ 只负责 FDIP，来自 memblock 的 Zicbop 软件预取 prefetch.i 由 ICache-top 处理，每周期只能收 1 个请求，且总是把软件预取排在高优先级——同一周期多条 prefetch.i 只有 1 条生效，其余被静默丢弃，性能收益低于预期。其二，密集 prefetch.i 会阻塞 FDIP 请求，反过来拉低性能。其三，prefetchPipe 要么处理 1 条 prefetch.i、要么处理 1 至 2 条 FDIP，即使两者在 SRAM 上并不冲突也不能并行，流水线利用率偏低。

新队列的做法是：先缓存软件预取请求，缓解丢失；再按队列空位与当前 FDIP 距离选择出队来源，解决阻塞；并允许 FDIP 与预取在同一周期并行发射，解决利用率。作者还留了扩展口——后续可以把 PDIP 一类算法的结果直接塞进同一队列。这是把预取从「一条通路」变成「一级可调度资源」的改法，比单纯调优先级更接近长期方案。

日期：2026-10-30　来源：XiangShan #6691

香山修 MBTB 对隐藏 VBTB 分支的分配抑制（10-30）

第 6750 号修的是预测器元数据互相压制的问题。VBTB 在预测时只暴露最早命中的那一条分支，但训练阶段仍可能命中一条「隐藏分支」——这条分支在预测时没被看到，却因为训练命中而抑制了 MBTB 的分配，结果是同一条分支反复预测失败。

改法分三处：只有在「预测时确实暴露过、且训练时仍驻留」这两个条件同时成立时，才因 VBTB 驻留而抑制 MBTB 写入；把全部 NumWay+1 条元数据条目传给 AlignBank，以便区分「VBTB 预测命中」与「SRAM 命中」；条件分支载荷只在真正 taken 时写入，因为 not-taken 的解决路径携带的是顺序下一条 PC 而非分支目标。最后一条同时施加于 MBTB 与 VBTB，并保留计数器训练与 IFU 失效请求（attribute=None）。改动只有 2 个文件、+33/−19，但属于「预测器越复杂、元数据口径越要对齐」的典型修复。

日期：2026-10-30　来源：XiangShan #6750

香山把 prefetch.i/r/w 解码为 LSU 预取操作（10-30）

第 6735 号改软件预取指令的处理流程：prefetch.i、prefetch.r、prefetch.w 在译码阶段被识别为 LSU 的预取操作，并从 CROB 中排除。这一步与第 6691 号的队列化改动配套——只有先把预取从「普通访存指令」里分出来，FTQ 侧的预取队列才有独立的请求来源，不必再与 load/store 争同一条提交路径。

日期：2026-10-30　来源：XiangShan #6735

香山 CI 性能流启用 lightSSS，GEM5 周测切到 261013 配置（10-30）

第 6802 号在 gsim 流程里升级 difftest 版本并让 CI 启用 lightSSS，跑分与验证共用同一套快照机制，省去重复构建。同窗口 OpenXiangShan/GEM5 的第 1274 号把每周 XSCC 测试切到 261013 配置档。两笔都属基础设施维护：前者决定「出错时能不能快速回放」，后者决定「周测跑的是哪一版编译器与负载组合」，不改变 RTL 行为。

日期：2026-10-30　来源：XiangShan #6802、GEM5 #1274

difftest 两天九笔：MMA 后端把 FP8 乘积打包进 cache word（10-30 至 11-01）

difftest 在三天里提交 9 笔，全部围绕 MMA（矩阵乘加）验证的性能，节奏上是一次集中攻坚。

最技术的一笔是第 1023 号：把相邻的 FP8 乘积记录塞进同一个 cache word 的低 16 位与高 16 位，省一半寄存器；每个 word 先用偶数 lane 初始化，解码前对两个半字分别掩码，保证相邻符号字段互不串扰，长度为奇数的尾块也照此处理。第 1021 号把比对搬到 GPU 上（11 文件、+420/−90）：DUT 快照上传与参考计算解耦，活跃结果行直接在 GPU 上比对，成功只回传状态字节，仅失配时才下载参考结果做诊断；回退路径用 memcpy 替代较慢的 SSE2 streaming-store；复用连续热槽并从 CUDA 服务直接上传其区间；去掉每个前缀的 ready／enqueue 确认，同时保住 LightSSS 会话生命周期。第 1018 号把 CUDA 传输、计算与结果校验流水化，第 1017 号让 LightSSS 支持 CUDA 后端，第 1020 号把 XDMA 中继请求打包以降延迟，第 1019 号简化有符号 INT8 参考归约，第 1016 号复用操作数槽的连续活跃前缀，第 1004 号隔离 Delta 与 AXI 时序。方向很清楚：验证器不再只求「算得对」，还要「算得起」。

日期：2026-10-30 至 2026-11-01　来源：difftest 提交记录、#1023、#1021

NEMU 为 AME 补 replay 状态回滚，修 hosttlb 矩阵寄存器选择符（10-30、10-31）

第 1255 号新增 replay_state.c（178 行），通过 replay state API 对矩阵寄存器、token 计数器、AMU 控制与同步事件做快照与恢复，并在 AME_MEM_ACCESS_CHECK 打开时同时跟踪矩阵与标量／向量存储，在 AME_TILEREG_UB_CHECK 打开时跟踪 tile 寄存器定义区；快照刻意独立于矩阵存储提交队列，避免回滚时被未提交的写操作污染。第 1274 号修一个签名不一致导致的功能错误：矩阵读写定义与调用方用的是 char m_name，公开头文件却声明为 bool isacc，于是经由头文件调用时 A/B/C 选择符一律被转成 true；修正两处声明，并在 host-tlb.c 里引入公共头，让今后再出现签名不匹配直接编译失败。

日期：2026-10-30、2026-10-31　来源：NEMU #1255、NEMU #1274

XSCache 修 CoupledL2 另一路 hint 被持续阻塞（10-30）

第 48 号只改一行：CoupledL2 里防止某一路 hint 被另一路持续阻塞。前一日第 46 号已把提示仲裁从固定优先级改为轮询，这一笔是同一条线的收尾。缓存层级里的饿死类问题通常只在长时间压力测试下显形，一行改动背后是一次不易复现的验证。

日期：2026-10-30　来源：XSCache #48

openRuyi 引入 llvm23 23.1.4，riscv64-openruyi-linux 默认 RVA23U64（10-30）

六笔提交里最重要的是新增 llvm23 包（1220 行 spec 加两个补丁）。补丁做的事情比版本号更有信息量：给 LLVM 增加 openruyi 这一 vendor，并把 riscv64-openruyi-linux 三元组的默认 ISA 级别直接定为 RVA23U64——也就是说不额外传 -march 时，编译器按 RVA23 生成代码。这对发行版是一个明确表态：RVA23 不再是「可选优化档」，而是默认基线；同时补丁也把 openruyi-linux 三元组接进 x86_64 与 riscv64 两套 Triple 处理路径，保证交叉构建可用。

其余五笔是滚动维护：ollama 升到 0.40.7 并标注 security-fixes；clang-wrap 更新到 20261030；新增 tree-sitter 的 C++ 与 Go 两个 Go 语言绑定包以及 go-pointer 依赖。官网新闻页最新仍是 2026.09 版（9-30 发布），10 月版尚未发布，10-19 的两篇（Ruyi Firmware、社区公共基础设施）已在 10 月中旬报告中收录，本期不重复。

日期：2026-10-30　来源：openRuyi 提交记录、llvm23 spec

CORE-V CVW 按 Svvptc 不再缓存无效 PTE（10-30）

第 1974 号修的是一个只在 RVA23 选项下才暴露的死锁：此前 HPTW 会把「遍历落在 V=0 的叶或非叶 PTE 上」的结果写进 ITLB/DTLB，之后命中该缓存项时一直从缓存条目触发 page fault，直到执行 SFENCE.VMA 才恢复。问题在于 Svvptc（RVA23 的可选项）允许处理程序把 V 置 1 后直接重试、不发 SFENCE.VMA——在这种合法用法下，缓存了无效 PTE 的实现会永久 fault。改法是让遍历器自己走既有 FAULT 路径从 LEAF 报错，不往 TLB 写任何东西，下一次访问重新遍历即可看到更新后的 PTE；相应地 tlbcontrol 不再检查 PTE.V，ITLB 的 ENVCFG_ADUE_1 覆盖排除也从第 18 行移到第 16 行。这是「规范给了你一个可选项，实现必须为它的合法用法留出通路」的典型案例。

日期：2026-10-30　来源：CVW #1974

CORE-V CVW 修 trace 的 VM 字段与 quad 溢出检测，rv64gc 覆盖率达 100%（10-30）

CVW 窗口内 19 笔提交，除 Svvptc 外还有三条值得记。第 1909 号修 wallyTracer 的 RVVI 跟踪字段：pte、页类型、ppn、虚拟／物理地址与访问类型的上报此前会带上「上一次遍历」的陈旧值（TLB 命中时常常是陷阱处理程序的代码页），导致 ACT 功能覆盖被错误记录——现在改为上报本次访问实际使用的翻译，ITLB 与 DTLB 的遍历分开捕获，RV64 上按 TLB 项影子化 PTE[60:54]，A/D 更新锁存器在每次遍历结束时清零，32 位指令跨两个 parcel 取指时按第一段报 PC。第 1906 号修 quadword cacheline 溢出检测（align.sv）并补一条回归用例。第 2004 号把代码覆盖率改成按配置统计，rv64gc 达到 100%；此外还把 riscv-arch-test 升到 act4 775be78d4，并同步 act／sail 的 yaml 配置。

日期：2026-10-30　来源：CVW #1909、CVW #1906、CVW #2004

二、产品与生态动态

Qwenputer 把 RV32IM 编译进 Qwen3.5-4B 权重，用注意力状态当 RAM（10-30）

开发者 Divyansh Agrawal 于 10-22 发布的实验模型 Qwenputer，10-30 经中文媒体转述后进入大众视野。做法是把 RV32IM 指令集及扩展「编译」进 Qwen3.5-4B 的权重，用模型自带的 Gated DeltaNet 状态充当可精确定址的 RAM，从而在前向传播里跑真正的程序——不需要训练，编译器直接写出每个权重：注意力头做查表、前馈单元以查找表实现算术、DeltaNet 头持有内存。

可核对的收益集中在精确算术：大整数乘法从原版 55.0% 升到 97.5%，大整数除法 72.5% 到 97.5%，加减 87.5% 到 97.5%，多次乘除的更长链路 90.0% 到 100%，合成整数算术 75.0% 到 97.5%；长整数基准 NUPA 从 48.6% 到 100%。项目自述该 CPU 通过官方 RISC-V 测试，连续执行约 1,800 万条指令无错；还实验性地做了「模型内文件系统」，在 GDN 状态里存最多 512 个文件、约 5.3 万词元。

代价同样明确：模型体积涨到约 18.8GB（接近原版两倍），每条 CPU 指令要生成多个词元，原本毫秒级的计算可能拖到数秒，运行还需专用驱动，不能像普通模型那样直接加载；项目已在 Hugging Face 与 GitHub 开源，可在单张 24GB 显存显卡上跑。这条对 RISC-V 圈的意义不在性能，而在于「RISC-V 作为确定性执行层被另一种系统借用」——它验证了 RV32IM 这套极简 ISA 适合被形式化地嵌入异构载体。

日期：2026-10-30　来源：IT之家报道（搜狐转载）、技术解析

进迭时空建 Bianbu AgentOS 伞仓，端侧 agent 栈按子模块锁定（10-30）

spacemit-com 新开 bianbu-agentic 伞仓并完成 bootstrap：它本身不 vendor 代码，只用子模块为每个组件钉住一个 commit，使整机镜像可以从单个 SHA 复现。仓内列出的组件构成一套完整的端侧 agent 操作系统：agent runtime（YAML 驱动的会话事件流、生命周期、模型调用、工具／插件执行与安全边界，Python）、agent-security（工具审批、按 agent 同步能力、securityd 签名清单，含 Debian 打包）、agent-memory（Rust，L1 会话抽屉／L2 工作抽屉／L3 长期抽屉）、bibit-intent（意图路由与工具执行：确定性规则 → 本地推理 → 云端升级）、BiBit GUI（基于 Jan 的桌面前端，Tauri）、bibit-voice（KWS 唤醒、VAD、ASR，经 /run/bibit/audio.sock 提供服务）、bibit-filesearch（本地语义文件检索，数据不出机器）与 lxqt-schedule。

这套划分值得注意的地方是「记忆」被做成了独立子系统并分三层，而「安全」被做成带签名清单的常驻守护进程——两者都是把 agent 从演示品做成可交付系统时才会出现的部件。对 K 系列这类 RISC-V 端侧平台，这意味着厂商的软件重心正从「驱动与 ROS 文档」上移到「运行时与系统服务」。

日期：2026-10-30　来源：bianbu-agentic 仓库、README

进迭时空 docs-chip 移除 P1S 文档，docs-product 更新 K3 Pico 资源链接（10-30）

docs-chip 删除了 P1S 产品文档及其评审工具引用：中英文 power_stone 目录下的 P1S 页面、导航链接，以及文档评审 agent 里的 casing 检查、芯片路径查找、术语表、system prompt、实体元数据与 Copilot 指令一并清理。docs-product 合并第 153 号，更新 K3 Pico 的硬件资源链接。前者是产品线收敛的信号（文档与工具链同时去掉一条产品），后者属交付文档的常规维护。

日期：2026-10-30　来源：docs-chip 提交、docs-product #153

Radxa Linkr 增 OBS 浏览器采集指南，初始化 linkr-now-skill（10-30）

Radxa 的浏览器远程管理产品线窗口内 4 仓有推送：docs 增加 OBS 浏览器采集（browser capture）指南，linkr-docs 与 linkr-docs-en 同步更新，linkr-now-skill 完成初始化（Go）。Linkr 面向开发板与 NAS 的远程带外管理，OBS 采集指南说明其视频通路开始被当作直播／录制源使用，属使用场景扩展而非内核或固件变更。

日期：2026-10-30　来源：linkr docs 提交、linkr-now-skill

三、国内团队深挖

芯来发布 Nuclei Studio VS Code IDE 预览版（10-30）

芯来 10-30 在深圳发布 Nuclei Studio VS Code IDE，官方开发工具从此有 Eclipse 与 VS Code 两种形态。当前是 Windows 开发者预览版 0.1.0，中英文界面，以 VSIX 装进现有 VS Code（要求 1.134.0 以上），与已装扩展不冲突；底层仍依赖 Nuclei Studio IDE 2025.10。

兼容策略是「不重写、尽量照搬」：VS Code 版可直接导入 Eclipse 版工程，内置 cproject 兼容处理，打开即可开发；新建工程向导与 Eclipse 版一致（选厂商、SoC、开发板、SDK），SDK 与 BSP 仍以 NPK 包分发，两版可互换。调试支持 OpenOCD、J-Link、QEMU 与 NucleiModel 四种方式，统一走 CDT gdbtarget，断点、单步、变量、调用栈、内存与外设寄存器视图、串口监视器、反汇编齐备，并新增 Live Watch。AI 侧不设墙：常规 AI 编程助手装上即用，兼容 Kimi、GLM、DeepSeek、Qwen；官方演示用 Kimi Code 以 @helloworld 接管工程，一句话把 CoreMark 项目改成 AES-256-CBC 演示，随后直接在 QEMU 里调试并由串口打印 PASS。路线图列出 Linux 与 macOS 支持、profiling、代码覆盖率、ETrace、flash 编程与更多 AI 助手。

对国内 RISC-V 开发者生态而言，这一步的实际意义是「入口迁移」：Eclipse 启动慢、笨重是长期抱怨，而 VS Code 侧又能顺手接上本地或云端模型。工具链文档同步跟上 2026.10 发布——xlmodel 文档、工具链文档、QEMU XEC 以太网指南英文化、Studio 的 npk／gdb trace／大端调试说明，以及 xxlvfbf／xxlvw／xxlvqmacc 自定义扩展文档的英文化，共 5 笔。

日期：2026-10-30　来源：Design & Reuse 发布稿、nuclei-tool-guide 提交

算能 LLM-TPU 支持 InternVL3／LLaMa3，修 Qwen3-ASR 解码退化（10-30）

LLM-TPU 合入第 178 号（支持 InternVL3、LLaMa3，并优化 Qwen2_VL）与第 182 号。后者是一个值得记录的实际缺陷：forward_next 把 lm_head 的输出经 d2d 拷进 embed_cache 的 input_ids。当 --do_sample 且 lmhead_with_topk=false 时，lm_head 输出的是完整的 [1,151936] logits（607232 字节），把它拷进 4 字节的 token-id 缓冲，会在每个解码步破坏 embedding 查表，输出退化成重复垃圾 token（例如把 language Chinese<asr_text> 变成 languagelanguage...）。修法是在该分支改喂 greedy_head 的 token_id（4 字节），与 Qwen2_VL 的 forward_next 对齐；作者在 CV84X6 与 1684X 两块板上与 HF 逐 token 比对一致，回滚改动可复现原垃圾输出，确认因果。

另有一笔 sophon-tools 的更新：se-rag-core 把状态标记改为 24 小时自动刷新，版本升到 1.5.4。同窗口 sophgo 的 libsophon、middleware、osdrv、linux_5.10、build、sophpi、sophon-tools 等 10 个仓库在 10-31 同一分钟批量推送，属 SDK 侧的整批同步，未见单项功能说明。

日期：2026-10-30　来源：LLM-TPU #182、LLM-TPU #178、sophon-tools 提交

达摩院玄铁与奕斯伟窗口内组织级零新开发（11-02）

XUANTIE-RV 在窗口内零推送，最近一次是 torq-tile 的 10-29 14:14（北京时间，早于窗口起点），llvm-project 与 bcc 分别停在 10-27 与 10-21；奕斯伟 eswincomputing 最近推送是 10-19 的 linux-stable。两家在 72 小时窗口内没有可核对的新开发成果。需要说明的是，这并不代表产品线静默——玄铁在 10-19 峰会公布的 C950 多核互联／AI 推理／服务器 Java 进展与车规 E908A，已在 10 月下旬各期报告中收录，本期不重复。

日期：2026-11-02　来源：XUANTIE-RV、eswincomputing

四、具身智能与机器人专章

进迭时空新增统一机械臂控制框架，85 文件落标定／诊断／运动学（10-30）

spacemit-robotics/manipulation 一次性提交 85 个文件、+8605 行，建立了统一的机械臂控制框架。目录结构按能力切分：calibration 含 charuco 标定、手眼标定 CLI 与采样工具，diagnostics 有 arm_check 与操作员 CLI，kinematics 提供基于 URDF 的正解，motion 是设备服务与 CLI（device_service.cpp 234 行），bindings/python 给出 spacemit_manipulation 客户端与算子支持层，构建侧用 CMake 的 driver_modules 组织驱动模块。

这个结构透露的判断是：厂商把机械臂当成「有标定、有诊断、有运动学、有服务接口」的系统部件，而不是一段示例代码。手眼标定与 charuco 是实机部署绕不开的前置工序，arm_check 与设备服务是把机械臂接入 agent／上层调度所需的最小接口。对 RISC-V 机器人栈来说，这类「工程骨架」比单个算法 demo 更能说明落地进度。

日期：2026-10-30　来源：manipulation 提交

进迭时空 dice_arena 加入集成骰子游戏应用（10-30）

dice_arena 新增一个集成式骰子游戏应用，同批还有 pyagxarm（机械臂 SDK 绑定）与 humanoid 相关仓库的推送。就内容看，dice_arena 属演示型应用，用低自由度任务串起感知—决策—执行链路，价值在于给整套栈一个可复现的端到端样例。

同时需说明口径：spacemit-robotics 窗口内 5 个仓库的 pushed_at 有更新，但 humanoid_common 与 humanoid_unitree_g1 在 main 分支上没有窗口内新提交，属其它分支推送；humanoid_common 的实体提交应以前一周期记录为准，本期不重复计数。

日期：2026-10-30　来源：dice_arena 提交、spacemit-robotics

进迭时空 docs-ros 补英文 RealSense 指南，对齐中英文档（10-30）

docs-ros 新增英文版 RealSense 指南并对齐文档结构。此前该站的深度相机内容以中文为主，英文侧缺对应条目；这次补齐后，K3 平台上的视觉感知链路（相机接入、标定、与 ROS 2 节点的对接）在中英文两侧口径一致。对海外开发者与国内做出口方案的团队，这类文档对齐常是先决条件。

日期：2026-10-30　来源：docs-ros 提交

五、总结与趋势观察

一、内核侧的关键词从「支持」转向「按硬件能力调度」。 Linux 7.4 把快非对齐访问的判定从编译期挪到运行期，一条 7.3 时代只能留在定制内核里的优化，现在发行版内核默认就能带上，Tenstorrent 自测的带宽收益上限是 11%。同批并入的 hwcap／hwprobe 的「B」扩展与 Zic64b 上报，正是这类运行期决策的数据来源。对国内几家 RISC-V 发行版，这是零成本收益，但前提是芯片在 hwprobe 里如实上报——硬件厂把能力报全，比多做一次微架构优化更能让用户立刻受益。

二、香山前端进入「预取队列化」阶段。 第 6691 号把 iprefetch 从 ICache-top 的「每周期 1 条」逻辑上收到 FTQ，先解决丢失与阻塞，再谈 PDIP 一类算法；配套的 MBTB／VBTB 修正说明瓶颈已从「取指带宽」转向「元数据精度」。两条线合起来看，前端优化正在从加缓冲转向「把预取当成一级可调度资源」，这类改动的收益要靠长期负载才能验出来，短期跑分未必好看。

三、差分验证开始为加速器算子付性能成本。 difftest 三天 9 笔全部围绕 MMA：FP8 乘积打包、GPU 侧比对、CUDA 流水化、XDMA 中继打包、LightSSS 支持 CUDA 后端。RISC-V AI 核要走量产，验证吞吐必须跟上算子复杂度，否则「算得对」会变成「算不完」。这组改动的方向比单笔收益更值得记录。

四、工具链两侧同时定基线。 openRuyi 引入 llvm23，并把 riscv64-openruyi-linux 三元组的默认 ISA 定到 RVA23U64；芯来把 IDE 从 Eclipse 迁到 VS Code，并把 xlmodel、工具链与大端调试文档同步到 2026.10。前者定「默认生成什么代码」，后者定「开发者从哪里进来」，两者都属于长周期决定，短期看不到效果，但会影响此后一两年的默认选择。

五、国内侧本周期产出集中在算能与芯来，路线从板卡上移到系统栈。 算能的实质工作是模型支持与一个解码退化 bug 的修复（logits 拷进 4 字节 token 缓冲，导致每步解码破坏查表），这类缺陷只有真机逐 token 比对才能定位；芯来把工具链入口换到 VS Code 并顺手补齐 AI 助手接入。玄铁与奕斯伟在窗口内空档，进迭时空则同时推进 Bianbu AgentOS 伞仓与机械臂控制框架——一家公司把「端侧 agent 运行时」和「机械臂标定／诊断／运动学」并列推进，说明其 RISC-V 软件栈的重心正从驱动与文档转向可交付的系统层。本期新闻侧偏薄：中英文查询去重后实质新增只有 Linux 7.4、Qwenputer、Nuclei Studio 三条，其余为股市稿、消费电子与旧文重发；开源侧仍是主体。

附录

完整信源清单

信源核查表

信源 核查结果
Google News（中英文 27 组查询） 窗口内去重后实质新增 3 条：Linux 7.4、Qwenputer、Nuclei Studio；其余为股市行情稿、消费电子、旧文重发与博彩类噪音，已剔除
Hacker News 2 条：Linux 7.4（有效）；RVA23 之后演进的 Ubuntu 博客（原文 9-15，属旧文，不计条目）
Phoronix 窗口内 RISC-V 专项 1 条（Linux 7.4）；其余为显卡与存储子系统
CNX Software、LinuxGizmos、LWN 窗口内无 RISC-V 专项命中
riscv.org 官方博客 无新文；首页横幅为北美峰会征稿截止提示
openRuyi 官网新闻页 最新仍为 2026.09 版（9-30）；10 月版未发布，10-19 两篇已在前序报告收录
openRuyi 主仓 6 笔提交，含 llvm23 23.1.4 新增与 ollama 0.40.7 安全修复
riscv100.top 巡检 显著：新增 1 条 10-17 记录（XSCC 2.0 on 香山 KMHv3 RTL 3GHz，int 68.41、fp 76.95），下榜 2 条；What’s New 与委员会成员无变化
RISC-V 会员企业官网巡检 巡检 391 家（67 家抓取失败），更新项均为高校与机构首页常规内容，无实质产品、融资或架构动态
GitHub 重点仓库 香山 4 笔、difftest 9 笔、NEMU 2 笔、XSCache 1 笔、GEM5 1 笔、CVW 19 笔、CVA6 0 笔、openRuyi 6 笔、算能 5 笔、进迭时空 11 笔、芯来 5 笔、Radxa Linkr 4 笔
乐鑫（espressif） 窗口内 58 仓推送，属按日批量同步，未见 RISC-V 专项变更
达摩院玄铁、奕斯伟 窗口内组织级零推送，最近提交分别为 10-29 与 10-19