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 虚拟 ISAVirtual 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/降层链路之间的契约。这里出现的 ASAssembler/结构化表示在本仓库手册语境中对应「用于验证与变换的结构化强类型表示」与第 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.hppAPI 形态的权威来源。指令的公开 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: layoutrow_major, dtypeint8 context: backend_profileA3, op_locline 42该示例中tmatmul即真实存在于指令集中的TMATMUL矩阵乘指令见 docs/isa/TMATMUL_zh.mdfractal_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.hppAPI 形态双源对齐并由docs/tools/下的检查脚本自动化兜底兼容优先增量演进破坏性变更必带版本与迁移说明未知必需字段必拒弃用结构保留至少一个兼容窗口仓库中 v9.2.0 接口清理即为实例诊断必须含操作标识与定位、期望 vs 实际差异、确定性错误类别与附录 C 的PARSE_*/STRUCT_*/LEGAL_*/ORDER_*/BCODE_*分类对齐一致性以结构验证正反例、画像合法性矩阵、IR/字节码往返、逐指令差分检查四类场景为底线并在 CI 中固化。对于编译器/IR 工程师本文可作为实现 AS 验证器与降层管线的契约清单对于后端工程师本文可与第 11 章后端画像与一致性配合作为画像文档与合法性验证器的设计基线对于内核开发者理解这些契约有助于判断哪些行为是架构承诺、哪些是后端实现细节从而写出跨后端可移植的 PTO 程序。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考