企业官网建设流程全解析

PTO 虚拟 ISA 状态与类型契约解析：Tile 合法性维度、有效区域语义与诊断要求

【免费下载链接】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 虚拟指令集架构（Virtual ISA, VISA）手册的第三章《状态与类型》，系统讲解架构层可观察的状态模型、类型类别（type class）契约、Tile 合法性约束、有效区域（valid region）语义、指令属性契约以及诊断要求。读完本文，你将掌握 PTO 内核与编译器后端在进行类型检查、合法性校验、有效区域迭代与错误报告时必须遵守的架构级规则，并能在仓库源码（include/pto/common/type.hpp、include/pto/common/pto_tile.hpp）与指令文档（docs/isa/）中逐一印证这些规则。

本章在手册中的定位

本文所述内容对应 docs/mkdocs/src/manual/03-state-and-types_zh.md（英文原版见 03-state-and-types.md），是 PTO 虚拟 ISA 手册的第 3 章。按 手册索引 规定的阅读顺序，读者应在掌握第 2 章"执行模型"之后阅读本章，再进入第 4 章"Tiles 与 GlobalTensor"、第 5 章"同步"等章节。

根据手册前言（docs/mkdocs/src/manual/index.md），本手册定义的是"架构级契约"：它规定符合规范的 frontend、IR pipeline、backend 与 runtime 在执行 PTO 程序时必须保持的性质；而每条指令的具体语义以docs/isa/*.md指令页为准，本手册在其上定义系统级契约。当文档出现冲突时，按如下权威顺序裁决：

1. docs/isa/*.md：逐指令的语义与约束；
2. include/pto/common/pto_instr.hpp：公开 API 面与重载形态；
3. 本手册：架构分层、契约与一致性策略。

因此，第 3 章给出的"状态模型与类型契约"是连接指令页（微观语义）与后端实现（合法化、代码生成）的中间层规范。

1. 范围：什么属于本章定义的架构状态

原文档第 3.1 节（Scope）明确了本章的边界：本章定义 PTO 虚拟 ISA 操作可见的架构状态模型，以及类型层面的契约。这里有两个关键词：

• 架构可见（architecture-visible）：只有那些能影响程序可观察行为的量才属于架构状态；
• 类型契约（type-level contracts）：指令消费与产生值的类型约束。

与此相对，后端内部临时状态不在本章范围内，除非它改变了架构可观察行为。这是典型的 ISA 分层设计原则：后端（如 CPU 仿真后端、NPU 目标）内部的寄存器分配、流水线暂存、内部缓冲等实现细节可以自由变化，只要不越过架构契约的边界。这一原则也体现在 docs/isa/conventions_zh.md 中——指令页只声明"架构语义"或"后端补充"哪一层由它定义（见 附录 B 指令契约模板 中 Scope 小节的要求：页面 MUST 声明其定义的是架构语义还是后端特定补充）。

2. 架构状态模型：四类概念状态

原文档第 3.2 节将架构层抽象为以下四类概念状态（conceptual state）：

这四类状态构成了 PTO 程序的"世界"：数据要么位于片上 Tile 存储（Tile 值），要么位于片外全局内存（GM 视图），要么是标量/立即数形式的控制参数，而同步/事件状态则负责在这些值之间建立顺序约束。与第 10 章"内存顺序与一致性"（10-memory-ordering-and-consistency.md）呼应，第 4 类状态正是排序操作（ordering operations）所观察的对象。

从源码结构看，include/pto/common/type.hpp中的pto::TileType枚举（见下文第 4 节）与include/pto/common/pto_tile.hpp中的pto::Tile模板，正是"Tile 值及其元数据"这一状态类别的 C++ 具体化；pto::GlobalTensor、标量类型与事件 API 则分别对应其余类别。四类状态与 docs/isa/conventions_zh.md 中的记号约定一一对应（Tile / GM / 标量-立即数 / 事件）。

3. 类型类别：指令操作数的类型契约

原文档第 3.3 节定义 PTO 虚拟 ISA 的类型类别（type class）：

• Tile 类值（!pto.tile<...>类）；
• 内存/全局视图（!pto.memref<...>或等价类）；
• 标量整型/浮点/index 类；
• 用于同步依赖的事件/token 类。

这里的!pto.tile<...>、!pto.memref<...>是 IR 层面的类型记法（对应手册第 8 章"虚拟 ISA 与 IR"，见 08-virtual-isa-and-ir.md），其核心作用是把"值该放哪、能怎么用"编码进类型系统。

类型类别契约的关键规范是：每个指令族 MUST 为每个操作数/结果位置定义可接受的类型类别。也就是说，类型合法性不是全局统一的，而是"按位置（position）"约定的——同一个指令族中，dst、src0、src1各自可能有不同的类型类别要求。这一点在 附录 B 指令契约模板 的 Operands 小节得到落实：每个操作数/结果 MUST 定义 role（dst/src0/src1/…）、类型类别、域/形状期望以及位置/布局要求（如有）。

在实际指令页中，这一契约以"操作数表"形式出现：例如TLOAD/TSTORE同时消费 Tile 类与内存视图类操作数，TADD等计算指令只消费 Tile 类与（在*S/*C变体中）标量/立即数类，同步指令（如 SYNCALL、set_flag/wait_flag模式）则操作事件/token 类。约定细节可参考 docs/isa/conventions_zh.md 的"记号"一节。

4. Tile 合法性维度：dtype、形状、角色与布局

原文档第 3.4 节指出，Tile 合法性（legality）受以下维度约束：

• 元素类型（dtype）：如fp16、fp32、int8、int16、int32、uint8、uint16、uint32等；
• 形状与有效区域兼容性：物理形状（capacity shape）与有效形状（valid shape）之间的关系；
• 位置-意图角色（location-intent role）：Mat/Left/Right/Acc/Bias/Scale等；
• 布局与对齐约束：基础布局、盒化/分形布局以及对齐要求（后端支持子集）。

并且，虚拟 ISA 只定义合法性接口（legality interface），具体支持集合由后端画像（backend profile）定义。这意味着一张指令页列出的 dtype/layout/location 组合是"架构层允许的上限"，而某个具体后端（如 CPU 仿真器、A5、A2A3 等目标）实际支持哪些组合，由其画像单独声明（对应手册第 11 章 11-backend-profiles-and-conformance.md）。

4.1 位置-意图角色在源码中的具体化

位置-意图角色直接对应 include/pto/common/type.hpp 中的pto::TileType枚举：

enum class TileType { Vec, // 向量 Tile 存储（UB / vector pipeline） Mat, // 通用矩阵 Tile 存储（Matrix L1） Left, // 矩阵乘操作数 Tile（L0A） Right, // 矩阵乘操作数 Tile（L0B） Acc, // 矩阵乘累加器 Tile Bias, // 部分 matmul/move 路径的辅助 Tile Scaling, // 部分 matmul/move 路径的辅助 Tile ScaleLeft, ScaleRight, Ctrl, };

这些枚举值编码 Tile 的逻辑/物理存储类，参与重载选择与编译期检查（详见 docs/coding/Tile_zh.md）。docs/isa/中的指令页会声明每条指令允许哪些位置类型——这正是"位置-意图角色"维度的落地方式。例如矩阵乘（TMATMUL_zh.md）的操作数通常是Left/Right/Acc角色，而向量计算（如 TADD_zh.md）使用Vec角色。

4.2 布局与对齐约束

布局维度由pto::BLayout（基础布局：RowMajor/ColMajor）与pto::SLayout（盒化/分形布局：NoneBox/RowMajor/ColMajor）共同刻画，二者同样定义在 include/pto/common/type.hpp 中：

enum class BLayout { RowMajor = 0, ColMajor = 1 }; enum class SLayout { NoneBox = 0, RowMajor = 1, ColMajor = 2 };

对齐约束在 include/pto/common/pto_tile.hpp 中以编译期检查（static_assert）实现，其中TileConfig::alignedSize = 32（32 字节对齐）。典型规则（详见 docs/coding/Tile_zh.md）：

• 未盒化 row-major Tile：Cols * sizeof(Element)必须是 32 字节的整数倍；
• 未盒化 col-major Tile：Rows * sizeof(Element)必须是 32 字节的整数倍；
• 盒化 Tile：形状必须与(SLayout, SFractalSize)隐含的基块维度兼容。

这些约束"有意为之"：它们阻止生成在真实硬件上非法或低效的程序。同时注意 64 位 Vec Tile 的 32 字节对齐要求作用于物理形状（RowMajor 要求Cols % 4 == 0，ColMajor 要求Rows % 4 == 0），有效维度可以更小但须满足指令约束（见 docs/isa/conventions_zh.md）。

4.3 常用角色的便捷别名

include/pto/common/pto_tile.hpp提供了矩阵乘相关的便捷别名：pto::TileLeft<Element, Rows, Cols>、pto::TileRight<Element, Rows, Cols>、pto::TileAcc<Element, Rows, Cols>，它们自动为目标选择合适的盒化布局与分形大小（如 CPU 仿真后端中TileLeft为外层 col-major + 内层 row-major 的 "Nz" 形式，TileRight为外层 row-major + 内层 col-major 的 "Zn" 形式）。

5. 有效区域语义：架构一等语义

原文档第 3.5 节将**有效区域（valid region）**提升为"架构一等语义（first-class）"，包含三条规范：

• 语义定义仅作用于声明的有效域索引：即数学语义只在有效域内有定义；
• 有效域之外的值在未明确说明时为未指定（unspecified）：不要假设域外元素一定清零或保持不变；
• 多输入操作 MUST 定义域兼容规则：当指令有多个输入（如src0、src1）时，必须明确它们的有效域如何兼容。

标准记号使用Rv与Cv表示有效行/有效列。

5.1 记号与查询接口

在 docs/isa/conventions_zh.md 中，有效区域写作(valid_row, valid_col)，运行期通过GetValidRow()/GetValidCol()查询。当指令页写"对有效区域内每个元素(i, j)"时，默认含义为：

• valid_row = dst.GetValidRow()、valid_col = dst.GetValidCol()（除非指令显式定义不同的迭代域，例如某些指令以源 Tile 的有效区域定义语义域）；
• 数学语义仅对0 <= i < valid_row且0 <= j < valid_col的dst[i, j]做出定义；
• 有效区域外元素的值为未指定。

对多输入指令，除非约束小节有更严格的要求，文档默认输入 Tile 与迭代域在形状/有效区域上是兼容的——这正是"多输入操作 MUST 定义域兼容规则"的实践形式。

5.2 物理形状与有效形状的区别

一个容易出错的关键点是：Rows/Cols描述物理存储形状，GetValidRow()/GetValidCol()描述有效区域；修改有效形状不会改变物理步长。对于非分形 Tile，元素(i, j)的偏移为i * RowStride + j * ColStride：RowMajor 步长为(Cols, 1)，ColMajor 步长为(1, Rows)。

conventions_zh.md 给出了一个 A5 上的具体反例：int64_t/uint64_t的 RowMajor 输出物理形状为[64,4]、有效形状为[64,1]时，物理行步长仍为 4 个元素（32 字节）；行归约结果位于偏移0, 4, 8, ...，若把有效列数 1 当成物理行步长，会导致行间结果错位；紧凑的 ColMajor[64,1]则使用连续元素偏移。

5.3 有效区域的静态与动态表达

在pto::Tile模板中，有效区域可以是编译期静态的，也可以是运行期动态的：当RowValid_ == Rows_且ColValid_ == Cols_时有效区域完全静态；当二者之一为pto::DYNAMIC（在 pto_tile.hpp 中定义为-1）时，有效值存储在 Tile 对象中，通过GetValidRow()/GetValidCol()查询。有效区域总是一个连续前缀（0 <= i < valid_row、0 <= j < valid_col）。

下面两个示例取自 docs/coding/Tile_zh.md，演示静态与动态有效区域的声明方式：

// 静态有效区域（mask）：127×127，域外以 0 填充 using TileT = pto::Tile<pto::TileType::Vec, float, 128, 256, pto::BLayout::RowMajor, 127 /*row_valid*/, 127 /*col_valid*/, pto::SLayout::NoneBox, pto::TileConfig::fractalABSize, pto::PadValue::Zero>;

// 动态有效区域（mask）：行有效数在运行期确定 using TileT = pto::Tile<pto::TileType::Vec, float, 128, 256, pto::BLayout::RowMajor, pto::DYNAMIC /*row_valid*/, 127 /*col_valid*/>; TileT t(/*row_valid_runtime=*/m);

注意，PadValue（如PadValue::Zero）是编译期策略，用于部分实现处理有效区域外元素（例如 select/copy/pad），其效果依赖指令与后端，不能默认假设域外行为。

6. 属性契约：指令属性的规范要求

原文档第 3.6 节规定，指令属性（例如比较模式、舍入模式、变换模式等）MUST 定义四类信息：

1. 类型与取值域约束（type/domain constraints）：属性允许哪些值；
2. 默认行为（default behavior，如存在）：未显式给出属性时的行为；
3. 对语义与合法性检查的影响：属性如何改变指令的语义和合法性判定；
4. 无效取值的诊断要求：属性取值非法时如何报告。

属性契约是"参数化指令"的核心：*S/*C变体指令（标量/立即数变体）、比较指令（TCMP_zh.md）、舍入类指令等都有各自的模式属性。在源码侧，这类模式通常以枚举表达，例如 include/pto/common/type.hpp 中的PrintFormat、MaskPattern（其注释还注明P0101 = 1等取值与指令VREDUCEv2的 pattern mode 保持一致），说明枚举取值与指令语义之间存在直接对应关系。

在文档侧，附录 B 指令契约模板 要求 Constraints 小节 MUST 列出合法性维度（dtype、layout、location、shape、mode attrs），并区分架构要求与后端画像限制；Semantics 小节 MUST 定义有效域迭代模型、域内输出含义，并显式处理域外行为（定义为指定或未指定）。这些要求与第 3.6 节"属性对语义与合法性检查的影响"前后呼应。

7. 诊断要求：类型/状态验证的错误报告规范

原文档第 3.7 节规定，类型/状态验证诊断 SHOULD 包含以下要素：

• 操作数位置（operand position）：出错的是dst、src0还是src1；
• 期望类型类别与实际类型类别（expected vs. actual）：便于快速定位类型不匹配；
• 相关合法性维度（dtype/layout/location/shape）：把非法组合的具体维度报出来；
• 面向 CI 稳定性的确定性错误标识（deterministic error identifiers）：错误标识在持续集成中必须可复现、可断言。

7.1 诊断分类学

附录 C：诊断分类学 进一步给出了 PTO 工具链的诊断分类体系，与第 3.7 节直接相关：

其中STRUCT_*（类型类别不兼容）与LEGAL_*（合法性维度组合）正是第 3.7 节"类型/状态验证诊断"的主要落点。附录 C 给出的推荐消息字段也与第 3.7 节逐条对应：错误类别（稳定标识）、操作名与操作数位置、期望契约摘要、实际违规值/形状/类型/模式、位置或源码上下文。

7.2 诊断示例

附录 C 提供了如下格式示例（引用自 appendix-c-diagnostics-taxonomy.md）：

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

这个例子同时体现了"操作数位置"（src1）、"期望 vs 实际"（expected/actual）、"合法性维度"（layout、dtype）与"确定性错误标识"（LEGAL_UNSUPPORTED_TUPLE）四项要求。

7.3 稳定性策略

附录 C 的稳定性策略明确了"确定性"的具体含义：错误类别标识 MUST 在补丁版本间保持稳定；消息措辞 SHOULD 保持稳定以支撑 CI 快照比对；若消息措辞发生实质性变化，发布说明 SHOULD 记录该变化。这与第 3.7 节"面向 CI 稳定性的确定性错误标识"互为表里，说明 PTO 把诊断稳定性当作工具链质量契约的一部分。

8. 从规范到实践：阅读与验证路径

第 3 章"状态与类型"是规范性的（其中MUST/SHOULD/MAY为规范语言，见 docs/mkdocs/src/manual/index.md），要将这些契约落到实际开发与调试中，可以按以下路径在仓库内验证：

1. 查指令契约：打开目标指令页（如 TADD_zh.md、TMATMUL_zh.md、TLOAD_zh.md），对照 附录 B 模板 检查其 Operands（类型类别/角色）、Constraints（合法性维度）、Semantics（有效域迭代与域外行为）、Diagnostics（拒绝条件）是否齐备。
2. 查通用约定：docs/isa/conventions_zh.md 汇总了全仓统一的记号（Rv/Cv、有效区域、物理/有效形状、步长、对齐）与事件同步约定。
3. 查类型与 Tile 编程模型：docs/coding/Tile_zh.md 详解pto::Tile的位置角色、布局、对齐与静态/动态有效区域；include/pto/common/type.hpp 提供TileType/BLayout/SLayout枚举的权威定义。
4. 查诊断契约：附录 C 提供诊断类别前缀、推荐字段与稳定性政策，可用于设计或断言工具链报错。

小结

PTO 虚拟 ISA 手册第 3 章用"状态模型 + 类型契约"两个支柱框定了内核与后端的契约边界：架构状态只包含 Tile 值（含有效区域元数据）、标量/立即数、全局内存视图与同步/事件状态四类；类型类别按操作数位置逐一约定；Tile 合法性由 dtype、形状、位置-意图角色、布局/对齐四维约束，且具体支持集合由后端画像决定；有效区域语义是一等的（域内定义、域外未指定、多输入须定义兼容规则）；指令属性必须声明取值域、默认行为、语义影响与非法值诊断；验证诊断必须包含操作数位置、期望/实际类型类别、合法性维度与确定性错误标识。这七组规则共同构成了"可移植、可验证、可诊断"的 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