mcpp-community
diff --git a/‎.agents/docs/2026-09-07-general-build-infrastructure-gaps-design.md‎
Lines changed: 109 additions & 12 deletions b/‎.agents/docs/2026-09-07-general-build-infrastructure-gaps-design.md‎
Lines changed: 109 additions & 12 deletions
@@ -462,26 +462,122 @@ Python 层(`pyasc`、`pypto`、框架适配)不在覆盖内;规模是数人年;*
 `exports`、`role = "manifest"`、探测库、以及 RDC 的昇腾对应物上。**四项够用则通过;
 不够则暴露第五项 —— 那正是想要的产出。**
 
-### 10.3 开工前的可行性闸
+### 10.3 调研结果(2026-09-07 实测)
 
-任一为否则不开始:(a) 有昇腾硬件或可用模拟器;(b) 切片内组件源码可得且许可允许;
-(c) 毕昇有稳定的厂商 URL 且可再分发。
+三处不确定已调研,**两处证实,一处未能证实**。仓库全部可匿名 clone
+(`gitcode.com/cann/*`,分支 `8.5.0`),许可为 CANN Open Software License Agreement 2.0。
 
-### 10.4 裁决判据
+#### 10.3.1 无硬件执行:存在,且是厂商自己的测试路径(证实)
 
-阶段一(`rules-ascendc` + 一个 hello kernel)的判据有两条,第二条是整个实验的重点:
+Ascend C 有**三种**运行模式,经 `-DCMAKE_ASC_RUN_MODE=` 选择:
 
-1. 在真机 / 模拟器上跑出正确结果,**断言设备名而非结果数值**(结果数值在静默回退时
-   同样正确)。
+| 模式 | 需要硬件 | 走不走岛 |
+|---|---|---|
+| `npu`(默认) | 是 | 是 |
+| `sim`(NPU 仿真) | 否 | **是**(见下) |
+| `cpu`(CPU 调试) | 否 | **否** |
+
+仿真器**随工具链发布**,按 SoC 分库:`${ASCEND_DIR}/*/simulator/<SoC>/lib`,
+`Findpvmodel.cmake` 里的目标是 `pvmodel_ascend910` / `pvmodel_ascend310p` /
+`pvmodel_ascend610` 与 `pem_davinci_ascend910B1` / `pem_davinci_ascend310B` /
+`pem_davinci_ascend610Lite`。**asc-devkit 自己的单元测试就链接它们**
+(`tests/unit/basic_api/ut/CMakeLists.txt`),所以这是厂商既有的无卡测试路径,
+不是我们发明的用法。
+
+**关键区分,而且它决定判据能不能用:**
+
+`cpu` 模式链接 `tikicpulib::${SOC_VERSION}` 并使用 `compiler/tikcpp/` 的头文件
+(实测于 `cmake/asc/legacy_modules/function.cmake`)。也就是说**同一份 kernel 源码由
+宿主编译器编译**,构建图里根本没有岛。用 `cpu` 模式跑绿,证明的是 kernel 数值对,
+**不是岛的机制对** —— 它没走那条路径。这正是本仓库反复付学费的形态:判据施加在
+错误的对象上。
+
+`sim` 模式则保留岛。**这一条是推断而非实测**,依据有二:它被称为"NPU 仿真"且用于
+验证 NPU 上的正确性;msOpProf 的 Simulator 模式采集**指令流水**数据,而指令流水只有
+在真正执行设备指令时才存在。**实现时必须先确认这一条**,方法是检查 `sim` 模式下
+是否仍调用 `bisheng`。
+
+#### 10.3.2 算子注册元数据:JSON,且按 SoC 分(证实)
+
+实测 `ops-math`(72 MB,`math/` 下 1451 个 `.cpp`、927 个 `.h`):
+
+```
+math/<op>/op_kernel/          设备侧
+math/<op>/op_host/            宿主侧
+math/<op>/op_host/config/<soc>/<op>_binary.json
+math/<op>/op_host/config/<soc>/<op>_simplified_key.ini
+```
+
+`math/` 一棵树里 166 个 JSON、143 个 INI。JSON 的内容是算子签名到**设备二进制文件名**
+的映射:
+
+```json
+{ "op_type": "Abs",
+  "op_list": [ { "bin_filename": "Abs_1c4543fdfe...",
+                 "inputs": [ { "dtype": "bfloat16", "format": "ND", ... } ] } ] }
+```
+
+**这是 `role = "manifest"` 的教科书用例**:一个数据文件,由本包之外的运行时按路径读取,
+以文件名指向设备产物。
+
+而且 SoC 目录有六个 —— `ascend310p`、`ascend910`、`ascend910_93`、`ascend910_95`、
+`ascend910b`、`kirinx90`。**注册文件是按目标条件化的**,因此这个切片同时压在
+`role = "manifest"` 与 SPEC-004 的目标轴上。
+
+另外两项确认:**源码布局本身已经是岛** —— 每个算子的 `op_kernel/` 与 `op_host/` 是分开
+的目录;设备架构标志是 `CMAKE_ASC_ARCHITECTURES=dav-2201`,与 `sm_89` 同类。
+
+#### 10.3.3 毕昇的可再分发性:未能证实(不利)
+
+毕昇不是独立发布物。实测路径是
+`${ASCEND_DIR}/compiler/ccec_compiler/bin/bisheng`(`ops-math/cmake/torch_extension.cmake`)
+—— 它在 **CANN 工具包内部**。而工具包的下载页要求接受 *CANN Software User License
+Agreement 2.0* 且看来需要登录;**没有找到稳定的匿名 URL,再分发条款也未确认**。
+
+这与 dpcpp 的处境不同,dpcpp 有可直接取的发布物。**这一条是本实验唯一真实的阻碍**,
+且它不是技术问题。
+
+#### 10.3.4 一个附带发现:CMake 把 Ascend C 当作一门"语言"
+
+`cmake/asc/ASCConfig.cmake` 注释写着 `plugin support ASC language`,并从
+`$ENV{ASCEND_HOME_PATH}/compiler/tikcpp/ascendc_kernel_cmake/ASC_CMake/FindASC.cmake`
+引入。开源仓库里只有 `include()`,**真正的设备编译机制在工具包内部**。
+
+两个推论:
+
+1. 移植意味着**读工具包自带的 cmake 来学会它发什么标志**,与 `rules-sycl` 驱动 dpcpp
+   的做法同形,不是新问题。
+2. 这是 §9 那条轴的第三方佐证:CMake 用 `enable_language(ASC)` 把它放进**引擎**,
+   mcpp 用规则包把它放进**包**。**同一条轴,不同的归属** —— 而归属正是 §7 要裁决的事。
+
+### 10.4 修正后的可行性闸
+
+初稿把"有硬件或模拟器"列为开工硬闸。**这条太严,已更正。** 闸应拆成两个:
+
+| 目的 | 需要 | 结论 |
+|---|---|---|
+| **架构验证**(本实验) | 无 | **可开工** —— 裁决判据 `git diff src/` 为空完全在构建期 |
+| **对用户可用** | `sim` 模式或真机 | `sim` 存在(§10.3.1),但受 §10.3.3 阻碍 |
+
+唯一的真实前置是 **§10.3.3:毕昇能否合规取得**。不解决它,连构建都跑不起来。
+可能的出路两条,均需人工确认:(a) 工具包是否允许在 CI 环境内自动下载安装;
+(b) 是否接受"用户自备工具包,mcpp 只按 `ASCEND_HOME_PATH` 定位"的形态 —— 后者与
+本生态"不用宿主"的不变量有张力,需要单独裁定。
+
+### 10.5 裁决判据
+
+阶段一(`rules-ascendc` + 一个 hello kernel)两条,第二条是重点:
+
+1. 在 `sim` 模式下跑出正确结果,**断言设备名/执行路径而非结果数值**(数值在 `cpu`
+   模式与静默回退时同样正确)。**不得用 `cpu` 模式充当这条** —— 理由见 §10.3.1。
 2. **`git diff src/` 为空。**
 
-第二条为否,即"这条架构主张在第一个陌生厂商面前就没成立" —— 这个结论比移植成功更有
+第二条为否,即"这条架构主张在第一个陌生厂商面前就没成立"。这个结论比移植成功更有
 价值,也更该早点知道。
 
-### 10.5 范围警告
+### 10.6 范围警告
 
-交付物是**验证物,不是承诺长期维护的 fork**。算子库切片钉在某个上游版本,不承诺跟随。
-否则这个实验会悄悄变成"维护一个 CANN 分支",而那不是任何人想签的字。
+交付物是**验证物,不是承诺长期维护的 fork**。算子库切片钉在 `8.5.0`,不承诺跟随。
 
 ## 11. 准入自检(docs/05 附录 A)
 
@@ -541,4 +637,5 @@ C6 值得单独说明:它是这批里唯一无法在开发机上验证的判据
 | 版本 | 变更 |
 |---|---|
 | 初稿 | 四处通用缺口:`exports`、`link-flag`、包内布局、探测库。配置头与包内布局在核实 main 后各自缩小 |
-| 修订 | 两处判断被推翻并就地更正:**RDC 归插件侧,引擎零改动**(§0.2);**stdpar 可岛化,初稿的"互斥"说法过头**(§8.1)。新增三处缺口(§6)、归属规则(§7)、编程模型三分法(§8)、术语对齐建议(§9)、以及用陌生厂商证伪的实验(§10) |
+| 修订一 | 两处判断被推翻并就地更正:**RDC 归插件侧,引擎零改动**(§0.2);**stdpar 可岛化,初稿的"互斥"说法过头**(§8.1)。新增三处缺口(§6)、归属规则(§7)、编程模型三分法(§8)、术语对齐建议(§9)、以及用陌生厂商证伪的实验(§10) |
+| 修订二 | §10 的三处不确定实地调研(§10.3),两处证实一处未证实。第三处更正:**"有硬件或模拟器"不是开工硬闸**,架构验证完全在构建期(§10.4);真实前置只有毕昇的合规取得。新增两条实测结论:`cpu` 模式**不走岛**因而不能充当设备判据(§10.3.1),以及 CMake 把 Ascend C 当作一门语言 —— 同一条轴、不同归属的第三方佐证(§10.3.4) |