PTO 虚拟 ISA 与 AS/IR 契约全解：三层分层模型、验证边界与降层不变量-迪斯科星球

PTO 虚拟 ISA 与 AS/IR 契约全解：三层分层模型、验证边界与降层不变量

【免费下载链接】pto-isaParallel Tile Operation (PTO) is a virtual instruction set architecture designed by Ascend CANN, focusing on tile-level operations. This repository offers high-performance, cross-platform tile operations across Ascend platforms.项目地址: https://gitcode.com/cann/pto-isa

本篇技术指南聚焦 CANN pto-isa 仓库中《PTO 虚拟指令集架构手册》第 8 章「虚拟 ISA 与 AS」所定义的架构级契约：它规定了 PTO 虚拟 ISA（Virtual ISA）语义与结构化中间表示（AS/IR）层、后端降层层之间的职责边界与约束。对于实现 PTO 降层链路的编译器/IR 工程师、目标合法化与代码生成的后端工程师、以及内核开发者而言，读完本篇后你将掌握 PTO 三层分层模型的完整定义、两级验证器的边界划分、降层必须保持的不变量、诊断的确定性要求，以及如何借助仓库中的一致性检查工具与指令文档体系将上述契约落地为可 CI 回归的工程实践。

1. 本章在手册体系中的定位与规范术语

PTO 虚拟 ISA 手册（入口见 docs/PTO-Virtual-ISA-Manual_zh.md，完整章节见 docs/mkdocs/src/manual/index_zh.md）将第 8 章「虚拟 ISA 与 AS」排在推荐阅读顺序的第 8 位，前承编程指南，后接字节码与工具链、内存顺序与一致性、后端画像与一致性。它回答一个核心问题：当一段 PTO 程序从前端进入 IR 流水线、再降层到具体后端时，哪些行为是架构级强制承诺（MUST），哪些是推荐要求（SHOULD），哪些是可选行为（MAY）。

第 8.1 节明确本章的范围：定义 PTO 虚拟 ISA 语义与 PTO AS/降层链路之间的契约。这里出现的 AS（Assembler/结构化表示）在本仓库手册语境中对应「用于验证与变换的结构化强类型表示」，与第 9 章 09-bytecode-and-toolchain_zh.md 中描述的「PTO IR 结构化形态」属于同一表示层次（详见第 2 节）。MUST、MUST NOT、SHOULD、MAY是贯穿全章的规范术语，其语义在手册 index_zh.md 第 0.4 节有统一定义：

MUST/MUST NOT：强制架构要求，违反即不合规；
SHOULD：推荐要求，偏离时需要明确理由；
MAY：架构显式允许的可选行为。

同时，手册第 0.5 节给出了权威来源优先级，这是理解第 8 章各条契约的前提：文档冲突时，依次对齐到 (1)docs/isa/*_zh.md（逐条指令语义与约束）、(2)include/pto/common/pto_instr.hpp（公共 API 形态与重载契约）、(3) 本手册（分层模型、架构契约与一致性策略）。第 8.6 节的「源同步规则」正是对这一优先级的工程化落实。

2. 三层分层模型：虚拟 ISA、AS 与后端降层

第 8.2 节定义了 PTO 的三层契约模型，这是全章的骨架：

虚拟 ISA 层：架构可见语义。这一层回答「指令在架构层面做什么」，由 docs/isa/ 下的逐条指令页面承载，例如TADD_zh.md、TMATMUL_zh.md、TPUSH_zh.md等，每条指令一页，描述操作数、语义、约束与诊断。
AS 层：用于验证与变换的结构化强类型表示。它是对虚拟 ISA 程序的机器可处理表达，承载结构验证、变换与序列化。与第 9 章对应，PTO 的表示层次为「虚拟 ISA 语义 → PTO IR 结构化形态 → 字节码序列化交换形态」。
后端降层层：目标相关合法化与代码生成。它把结构化表示映射到具体目标（A2/A3/A5、CPU 仿真器等后端画像）的实际实现。

模型的关键约束是：后端特化 MUST 保持虚拟 ISA 可观察行为。也就是说，无论后端如何做合法化（例如把一个操作拆成多条目标指令、调整 Tile 摆放），最终执行结果对架构语义的观察者而言必须与虚拟 ISA 定义一致。

这一分层在仓库源码中也有对应物：include/pto/common/pto_instr.hpp提供公共指令 API（虚拟 ISA 的 C++ 形态），include/pto/common/pto_instr_impl.hpp承载实现层，而include/pto/npu/（A5/A6 等 NPU 后端）与include/pto/cpu/（CPU 仿真器）分别提供目标相关实现——pto_instr.hpp通过#ifdef __CPU_SIM分支（pto_instr.hpp）选择 CPU 仿真路径，正是「一个 ISA、多后端特化」的工程体现。

3. AS 对象模型：结构化强类型表示的五大契约维度

第 8.3 节规定，一致性 PTO AS 模型 SHOULD 定义以下五个维度，这相当于 IR 层的「对象模型」：

模块与符号契约：一个 AS 模块由哪些符号组成，符号如何声明、解析与链接；
函数/基本块结构及顺序：函数、基本块的组织方式以及它们在模块中的排列顺序；
SSA 值拓扑：基于 SSA（静态单赋值）形式的值定义-使用关系，是验证与变换正确性的基础；
操作 schema（名称、操作数、结果、属性、副作用）：每个操作的形状描述，包括操作名、操作数/结果数量与角色、属性集合以及是否携带内存/同步副作用；
显式同步与内存副作用：事件、同步指令与内存顺序点在 IR 中的显式表达，避免隐式副作用破坏可验证性。

操作 schema 维度的规范写法可参考手册附录 B：指令契约模板：每条指令的 Operands 章节 MUST 为每个操作数/结果定义角色（dst、src0、src1等）、类型类别、域/形状预期与位置/布局要求；Constraints 章节 MUST 列出合法性维度（dtype、layout、location、shape、模式属性），并区分架构层要求与后端画像限制。

从源码角度看，include/pto/common/pto_instr.hpp的宏机制体现了「API 形态与实现分离」的契约精神：公开指令接口通过MAP_INSTR_IMPL、MAP_INSTR_IMPL_T、MAP_INSTR_IMPL_OUTS、MAP_INSTR_IMPL_ROLES等宏统一映射到API##_IMPL实现（pto_instr.hpp），在__CPU_SIM下还会经由PtoInstrTraceScope记录指令名、输出数量与操作数角色（PTO_INSTR_SCOPE_ROLES）。这套宏即是一种轻量的「操作 schema」：操作名、输出数量、角色列表被显式编码，供 CPU 仿真器的跟踪/验证链路消费。

4. 两级验证边界：结构验证器与目标合法性验证器

第 8.4 节将验证拆成两层，各自拥有明确的职责边界：

1. 结构验证器（IR 层）

MUST 验证操作 schema、元数（操作数/结果个数）、类型类别与必需属性；
MUST 与目标无关。即它只关心「程序在结构上是否自洽」，不关心「这条指令在某个后端上能不能跑」。

2. 目标合法性验证器（后端层）

MUST 验证选定后端画像下的 dtype/layout/location/shape 组合；
MUST 对不支持组合输出确定性诊断。同一输入在相同画像下必须产生相同的拒绝结果。

两层验证的边界设计让「结构正确性」与「目标可行性」解耦：前者保证 IR 流水线（解析、验证、变换、序列化）的通用性，后者保证每个后端画像的能力边界被显式、可预测地执行。后端画像的概念在第 11 章 11-backend-profiles-and-conformance_zh.md 中展开：画像 MUST 记录支持的指令族与操作形式、支持的 dtype/layout/location/shape 组合、同步与内存顺序限制、实现定义行为边界以及对不支持特性的诊断策略，画像可对应 A2/A3/A5/CPU 仿真器等具体目标。

结构验证与合法性验证失败时的诊断分类，在附录 C：诊断分类体系中有稳定命名：STRUCT_*类用于 IR 结构违规（元数错误、必需属性缺失、类型类别不兼容），LEGAL_*类用于后端/画像合法性失败（不支持的 dtype/layout/location/shape 组合、不支持的模式组合、画像中不支持的指令变体）。这两类恰好对应本章两级验证器的输出边界。

5. 降层不变量：什么可以动，什么绝不能动

第 8.5 节是全章最核心的约束条款，规定降层（lowering）过程中 MUST 保持的三类语义与一条 MUST NOT 红线：

降层 MUST 保持：

有效区域语义：操作作用的 Tile 有效区域（valid region）及其迭代模型不变，域外行为保持原定义；
显式顺序依赖：event、event synchronization（事件同步）、内存顺序点所表达的依赖关系必须在降层后被显式保留，不能被悄悄消除或重排；
架构定义域内的操作语义：操作在其架构定义的有效域内的含义不因目标相关变换而改变。

降层 MUST NOT：将实现定义行为（implementation-defined behavior）静默改写为架构定义行为。也就是说，后端在实现定义点上的具体选择不能在下层被当作架构承诺固化下来，否则会造成语义漂移，破坏「虚拟 ISA 可观察行为不变」的根本承诺。

「显式顺序依赖」这一维度的细节可结合手册第 5 章同步与编码指南 docs/coding/Event.md、docs/coding/Event_zh.md 理解：PTO 的事件对象是跨指令表达顺序依赖的显式载体（例如SYNCALL跨核同步屏障、WaitAllEvents显式等待），降层实现必须把这些依赖转换为目标后端的等价同步原语，而不能依赖隐式顺序假设。此外，docs/isa/conventions_zh.md作为指令参考的通用约定页（操作数、事件、修饰符），也从文档侧约束了这些依赖的书写与解释方式。

6. 源同步规则：语义意图与 API 形态的双源对齐

第 8.6 节要求 AS 契约 MUST 与两个来源保持同步：

docs/isa/*_zh.md：语义意图的权威来源。每页描述单条指令的架构语义（Scope、Syntax、Operands、Semantics、Constraints、Diagnostics、Implementation-defined behavior、Compatibility、Examples），其章节结构由附录 B 指令契约模板统一规范。
include/pto/common/pto_instr.hpp：API 形态的权威来源。指令的公开 C++ 签名、模板参数、重载契约以该头文件为准。

该同步关系在文档侧有明确声明：docs/isa/README_zh.md 开篇即注明「权威来源：include/pto/common/pto_instr.hpp」；同时，手册附录 D：指令族矩阵与docs/isa/manifest.yaml共同维护指令清单的完整覆盖。

更重要的是，这条规则在仓库中有自动化工具兜底（这为 8.9 节「一致性验证」提供了现成实现）：docs/tools/check_virtual_manual_consistency.py 的职责包括校验手册中英章节齐全、章节标题存在、MkDocs 导航顺序正确、附录 D 覆盖manifest.yaml中全部指令且每指令恰好出现一次、头文件清单（pto_instr.hpp）与 manifest 清单保持对齐、附录 D 生成同步（check_virtual_manual_consistency.py 的 docstring 逐条列出这些检查项）。此外 docs/tools/check_isa_consistency.py 进一步核查 ISA 文档自身的一致性。也就是说，「语义文档 ↔ 公共头文件 ↔ 手册矩阵」三者之间的同步不是靠人肉自觉，而是被脚本化、可进 CI 的。

7. 兼容策略：增量演进、版本迁移与兼容窗口

第 8.7 节给出 AS 契约的兼容策略四条：

SHOULD 优先采用增量 AS 演进（additive changes）：新增操作、字段、属性优于修改既有语义；
破坏性 AS 契约变更 MUST 包含版本与迁移说明；
未知必需字段 MUST 验证失败：解析器遇到不认识且标记为必需的字段必须确定性拒绝，而不是猜测语义；
已弃用结构 SHOULD 至少在一个兼容窗口内可解析：给下游迁移留出时间窗。

仓库中docs/isa/README_zh.md的「删除接口与迁移说明」一节正是这条策略的真实案例：自PTO ISA v9.2.0起，TADDC、TADDReluConv、TSYNC、TSUBVIEW、TPairReduceSum等一批历史指令接口的兼容窗口关闭、不再保留公开 wrapper，并给出逐条迁移路径——例如将TSYNC(events...)替换为普通 event 顺序表达（把 event 对象传给消费端 intrinsic，或在确需显式等待时调用WaitAllEvents(events...)），将TFUSEDMULADD重命名为TMADD、TMULADDDST重命名为TMULA，将融合 add/ReLU/convert 形态拆分为显式算术、转换/反量化与TRELU步骤等。这同时演示了「破坏性变更 MUST 包含迁移说明」与「兼容窗口关闭」两种机制的配合。版本兼容的整体策略还可参考 docs/coding/version-compatibility.md。

与第 9 章 09-bytecode-and-toolchain_zh.md 呼应，字节码层面的默认兼容策略与本章一致：未知必需字段拒绝；未知可选字段除非兼容模式显式允许否则拒绝；未知操作以确定性「未支持操作」诊断拒绝，并演进策略 MUST 定义 schema 版本字段、向后兼容窗口与未知字段/操作处理规则。

8. 诊断要求：确定性、可定位、可回归

第 8.8 节规定 AS/验证诊断 MUST 包含三类信息：

操作标识与定位上下文：报错要指出是哪个操作、位于何处；
期望与实际契约维度差异：不仅要报「错」，还要报「期望什么、实际得到什么」；
适于 CI 回归的确定性错误类别：错误类别标识稳定，脚本可按类别断言。

附录 C：诊断分类体系将整套分类细化为主诊断类别：PARSE_*（PTO-AS 文本解析：token 形态、文法违规、字面量/属性语法非法）、STRUCT_*（IR 结构：元数错误、必需属性缺失、类型类别不兼容）、LEGAL_*（后端/画像合法性：不支持的 dtype/layout/location/shape 组合、模式组合、指令变体）、ORDER_*（同步/顺序：缺失必需依赖边、非法同步形式、顺序契约违反）、BCODE_*（交换/序列化：不支持的字节码版本、section/record 畸形、未知必需字段/操作码）。附录 C 还给出推荐消息字段与稳定性策略：错误类别标识在补丁版本内 MUST 稳定，消息文案在 CI 快照中 SHOULD 尽量稳定，文案实质性变化应记入发布说明。

其示例格式直观展示了「期望 vs 实际 + 上下文」的诊断形态：

LEGAL_UNSUPPORTED_TUPLE: tmatmul operand src1 has unsupported tuple expected: layout in {fractal_a, fractal_b}, dtype in {fp16, bf16} actual: layout=row_major, dtype=int8 context: backend_profile=A3, op_loc=line 42

该示例中tmatmul即真实存在于指令集中的TMATMUL矩阵乘指令（见 docs/isa/TMATMUL_zh.md），fractal_a/fractal_b布局与 fp16/bf16 dtype 也是 PTO 矩阵指令的典型约束维度，可作为后端合法性验证器输出的实现参照。

9. 最小一致性场景与验证流水

第 8.9 节要求一致性验证 SHOULD 覆盖四类场景：

结构验证器合法/非法样例测试：同一验证器既要能接受合法程序，也要能确定性地拒绝非法程序（如元数错误、缺必需属性、类型类别不匹配）；
按后端画像划分的合法性通过/失败矩阵：对每个后端画像，按指令族/组合列出「应通过/应拒绝」的矩阵（对应第 11.6 节的必需测试矩阵）；
IR 与字节码往返检查：text -> IR -> bytecode -> IR -> text往返后保持语义、验证相关结构与必需元数据（不要求文本逐字节一致）；
与逐条指令语义对齐的差分检查：以docs/isa/*_zh.md的单指令语义为基准做差异比对。

这四类场景与第 9 章 09-bytecode-and-toolchain_zh.md 的验证流水一一对应，其建议流水为：前端生成 PTO IR → 运行结构验证器 → IR 序列化为字节码 → 字节码反序列化为 IR → 再次运行结构验证器 →（可选）运行目标合法性验证器，且 CI SHOULD 覆盖前 5 步。第 9.8 节进一步给出每次发布的运行验收清单：解析器正反例套件、结构验证一致性套件、畸形字节码鲁棒性测试、往返回归语料、诊断文案稳定性快照。

仓库测试体系为上述场景提供了载体：tests/npu/下按 a2a3、a5、a6、kirin9030、kirinDev0000、kirinX90 等目标组织大量指令级测试用例（例如tests/npu/a5/下的 st 用例），tests/cpu/提供 CPU 仿真侧的指令测试（如tests/cpu/st/），tests/run_st.sh、tests/run_cpu.py等脚本负责批量执行；文档侧的docs/tools/check_isa_consistency.py与docs/tools/check_virtual_manual_consistency.py则承担「文档—头文件—矩阵」一致性的回归检查。从源码结构看，这些工具与测试正是 8.9 节最小一致性场景在仓库中的落地形态。

10. 小结：从契约到实现的落地清单

第 8 章把「虚拟 ISA 与 AS/IR 之间的契约」拆解为可直接执行的工程要求，汇总如下：

分层：虚拟 ISA 语义、AS（结构化强类型表示）、后端降层三层各司其职，后端特化 MUST 保持虚拟 ISA 可观察行为；
对象模型：模块/符号、函数/基本块、SSA 值拓扑、操作 schema、显式同步与内存副作用五大维度 SHOULD 齐备；
验证：结构验证器（目标无关、验证 schema/元数/类型/属性）与目标合法性验证器（按画像验证 dtype/layout/location/shape 组合、确定性诊断）两级分工；
降层：MUST 保持有效区域语义、显式顺序依赖与架构域内操作语义，MUST NOT 把实现定义行为静默改写为架构定义行为；
同步：AS 契约 MUST 与docs/isa/*_zh.md（语义意图）、include/pto/common/pto_instr.hpp（API 形态）双源对齐，并由docs/tools/下的检查脚本自动化兜底；
兼容：优先增量演进，破坏性变更必带版本与迁移说明，未知必需字段必拒，弃用结构保留至少一个兼容窗口（仓库中 v9.2.0 接口清理即为实例）；
诊断：必须含操作标识与定位、期望 vs 实际差异、确定性错误类别，与附录 C 的PARSE_*/STRUCT_*/LEGAL_*/ORDER_*/BCODE_*分类对齐；
一致性：以结构验证正反例、画像合法性矩阵、IR/字节码往返、逐指令差分检查四类场景为底线，并在 CI 中固化。

对于编译器/IR 工程师，本文可作为实现 AS 验证器与降层管线的契约清单；对于后端工程师，本文可与第 11 章后端画像与一致性配合，作为画像文档与合法性验证器的设计基线；对于内核开发者，理解这些契约有助于判断哪些行为是架构承诺、哪些是后端实现细节，从而写出跨后端可移植的 PTO 程序。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析