前言

熟悉CPU指令集的人都知道，x86和ARM各自定义了一整套指令编码格式和操作语义，编译器按照这套规范生成机器码，硬件按同样规范解码执行。那昇腾NPU上的算子代码是如何从C++函数变成硬件可执行的二进制指令的？这中间起到桥梁作用的关键组件就是CANN体系中的PTO-ISA（Programmable Tensor Operation Instruction Set Architecture）。PTO-ISA定义了一套面向tile（数据块）操作的虚拟指令集规范，覆盖中间表示格式、tile抽象模型和二进制编码规则。对于编写昇腾NPU自定义算子的开发者来说，理解PTO-ISA的层级结构，是绕过编译链路中的隐性约束、写出高性能kernel的前提。

令人费解的"中间表示"：指令集为什么还有虚拟的？

写代码时，编译器帮我们把高级语言转换成机器码。这是大部分人的直觉。但昇腾NPU的算子编译链路不是一步到位的——它中间插了一层虚拟指令集。

一个常见的误区是：交给NPU执行的代码就是二进制机器码，编译过程就是把C++编译成这些码。实际情况恰恰相反。PTO-ISA正是一套运行在"硬件指令编码"之上的虚拟指令规范。它既不是最终执行的机器码，也不是普通的C++函数库，而是一套专门为tile级计算设计的中间表示协议。

类比一下：国际贸易中，不同国家的港口有各自的卸货设备和集装箱规格。为了让货物可以通行全球，国际标准化组织定义了标准集装箱的尺寸、锁扣位置和堆叠方式。每个港口按照标准改造自己的设备，货物就能在任意港口装卸。PTO-ISA就是昇腾NPU生态中的"标准集装箱规范"——它规定了tile这种数据块的结构、操作指令的编码格式、和硬件资源绑定的方式。不同代际的昇腾芯片（A2、A3、A5）各自实现这个规范，上层算子代码无需修改就能在不同芯片上运行。

PTO-ISA定义了90多条标准tile指令，涵盖逐元素运算、矩阵乘法、数据搬运、轴归约等算子开发中的常见操作。每条指令都有明确的输入输出类型、tile形状约束和事件同步语义。

Tile抽象：为什么要把数据切成块？

走进一个误区：既然NPU有海量的计算单元，为什么不直接对完整张量做运算，非要切成小块来处理？

这背后的原因跟物流管理如出一辙。假设你要把一个足球场那么大的货物运到一个只有标准集装箱门大小的仓库——你只能把货物切成可通行的尺寸，分批搬运。NPU的片上存储（类似寄存器文件或SRAM）容量有限，完整的张量可能占据数GB的全局内存，但片上tile存储区只能容纳几十KB。因此，数据必须以"tile"为单位分批搬运到片上，计算完成后写回全局内存。

PTO-ISA中的Tile是固定容量的二维缓冲区。它不是运行时动态分配的可变对象，而是一个编译期就确定形状的模板类型。以下是PTO Tile的完整类型声明：

pto::Tile<
  pto::TileType Loc_,         // 位置类型: Vec/Mat/Left/Right/Acc 等
  Element_,                    // 元素类型: float/half/int8_t 等
  Rows_,                       // 行容量（编译期固定）
  Cols_,                       // 列容量（编译期固定）
  pto::BLayout BLayout_ = pto::BLayout::RowMajor,  // 基础布局
  RowValid_ = Rows_,           // 有效区域行数（可静态或动态）
  ColValid_ = Cols_,           // 有效区域列数（可静态或动态）
  pto::SLayout SLayout_ = pto::SLayout::NoneBox,   // 盒化/分形布局
  SFractalSize_ = pto::TileConfig::fractalABSize,  // 基块大小
  pto::PadValue PadValue_ = pto::PadValue::Null     // 填充策略
>;

这段代码展示的是PTO Tile类型的完整模板签名。Tile是二维的，拥有编译期固定的行列容量（Rows_和Cols_），以及可选的运行时有效区域（RowValid_和ColValid_）。

编译期固定形状意味着编译器可以在生成指令时直接内联地址偏移量，无需运行时额外计算地址。有效区域（valid region）的设计则解决了"tile形状固定但实际数据不满"的矛盾——比如处理矩阵边缘的不对齐数据时，tile容量128x128，但有效数据可能只有96x80，有效区域允许表达这种"部分有效"的语义而不改变tile形状。这种编译期与运行时相结合的设计，来源于真实硬件上DMA引擎和矩阵计算单元对固定形状数据块的硬件偏好。

从中间表示到二进制编码：一条TADD指令的旅程

PTO-ISA的指令不只是一堆C++模板函数——它们在编译链路的末端会被编码为特定的二进制格式，由NPU硬件解码执行。这个过程让很多开发者感到神秘。用一个具体的例子来说明：一条TADD指令如何从代码变成硬件执行的二进制码。

#include <pto/pto-inst.hpp>
using namespace pto;

void example() {
  using TileT = Tile<TileType::Vec, float, 16, 16>;
  TileT a, b, c;
  TADD(c, a, b);
}

这段代码声明了三个16x16的float类型向量Tile，通过TADD指令将a和b逐元素相加写入c。从C++层面看，TADD就像是一个普通的函数调用。

TADD被设计为内建函数而不是运行时函数，目的是让编译器在编译期就获取到完整的操作信息——操作码（TADD）、操作数类型（float）、tile形状（16x16）、位置类型（Vec）。这些信息会被编译器用于后续的指令编码。如果改为运行时函数，编译器就丢失了这些关键信息，无法生成最优的二进制编码。

在编译链路的后端，这条TADD指令会经历以下编码阶段：PTO编译器将TADD的操作码映射到一个固定的二进制操作码字段，将三操作数（c, a, b）的片上地址编码到操作数字段，将数据类型和tile形状信息编码到修饰符字段。最终产出一条32字节或64字节的指令包，送入NPU的指令队列。

PTO-ISA指令的编码格式遵循一个统一的结构：每个指令包含操作码字段、操作数描述字段、事件同步字段和修饰符字段。这种分层编码的好处是，编译器和汇编器可以按照统一模板生成指令码，NPU的指令解码单元按同样的模板解析，代际之间的微架构变化只影响解码逻辑，不影响上层指令格式。

自定义算子编译链路的完整视图

昇腾NPU的自定义算子开发流程中，PTO-ISA扮演了几个关键角色。理解这些角色有助于避免常见的开发陷阱。

PTO-ISA处于算子开发链路的中枢位置。上层框架（PyTorch通过torch_npu，或通过PyPTO/PTOAS）调用PTO指令，PTO Tile Library提供这些指令的C++内建函数实现，BiSheng编译器将PTO指令序列编码为最终的NPU可执行指令。CPU模拟器则提供了脱离硬件的功能验证途径。

这个链路中最核心的设计哲学是"Auto / Manual双模式"。在Auto模式下，编译器自动处理tile的资源分配和同步插入，开发者只需描述运算逻辑：

// Auto模式：开发者只需关注运算逻辑
ascendc_library(no_workspace_kernel STATIC
  csrc/kernel/add_custom.cpp
)
ascendc_compile_options(no_workspace_kernel PRIVATE
  --cce-enable-pto-passes -O2
)

这段CMake配置代码启用了PTO编译通道（–cce-enable-pto-passes）。Auto模式下，开发者不需要手动调用TASSIGN来绑定tile到片上地址，也不需要插入TSYNC来保证流水线顺序。编译器自动分析数据依赖，插入必要的同步指令，分配片上存储。

Auto模式降低了上手门槛，让不熟悉昇腾硬件细节的开发者也能写出正确的算子。但代价是编译器无法针对特定问题做极致的调优——自动插入的同步点可能比手动优化版本更多，导致流水线空闲周期增加。Manual模式则把这些控制权交还给开发者：手动选择tile的片上放置位置（TASSIGN），手动管理事件同步（set_flag/wait_flag/TSYNC），手动排布指令顺序。两种模式服务于不同层次的开发需求。

在Manual模式下，开发者需要显式管理资源绑定和同步。以下是一个典型的手动放置代码片段：

using TileA = Tile<TileType::Left, half, 128, 64>;
using TileB = Tile<TileType::Right, half, 64, 256>;
using TileC = Tile<TileType::Acc, float, 128, 256>;
using TileUB = Tile<TileType::Vec, float, 128, 256>;

TileA a;
TileB b;
TileC acc;
TileUB ub;

TASSIGN(a, 0x1000);      // 将TileA绑定到片上地址0x1000
TASSIGN(b, 0x2000);      // 将TileB绑定到片上地址0x2000
TASSIGN(acc, 0x3000);    // 将累加器Tile绑定到片上地址0x3000

TLOAD(a, gm_a);          // 从全局内存加载数据到TileA
TLOAD(b, gm_b);
TMATMUL(acc, a, b);      // 执行矩阵乘法
TMOV(ub, acc);           // 将累加器结果移动到向量Tile
TSTORE(ub, gm_c);        // 写回全局内存
TSYNC();                 // 等待所有操作完成

这段代码展示了Manual模式下的一条完整计算流水线：数据从全局内存（GM）加载到片上tile，经过矩阵乘法计算，将累加器结果搬运到向量tile，最终写回全局内存。每一步的地址绑定和同步都是开发者显式控制的。

手动放置让开发者精确控制片上存储的布局，避免Cache冲突导致的性能退化。TASSIGN中的地址（0x1000、0x2000、0x3000）对应片上不同存储区（Matrix L0A、L0B、累加器寄存器），这些区域的访问延迟和带宽特性各不相同。正确的地址分配可以降低指令依赖链长度，让CUBE计算单元和MTE数据搬运单元重叠执行。

使用PTO-ISA前后效率对比

引入PTO-ISA之后，昇腾NPU上的自定义算子开发效率和运行性能都发生了实质性改变。以下表格对比了使用PTO-ISA前后的典型差异：

维度	使用前（直接面向硬件编码）	使用后（基于PTO-ISA开发）	差异来源
跨代移植成本	每代芯片需重新适配指令编码和存储映射	同一份PTO代码可编译到A2/A3/A5	PTO虚拟ISA层屏蔽代际差异
调试验证效率	需在NPU上反复烧录运行，单次迭代分钟级	CPU Simulator秒级验证，Auto模式自动排错	CPU-SIM模拟器+编译期约束检查
同步管理复杂度	开发者自行维护set/wait/TSYNC序列	Auto模式自动插入同步；Manual模式保留控制权	双模式设计覆盖不同开发需求
算子表达抽象层级	操作数据位宽、地址偏移、流水线阶段	tile形状+有效区域+布局修饰符，贴近数学语义	Tile抽象模型封装硬件细节
编码调试难度	直接查看二进制指令码排查错误	通过PTO指令列表（90+条标准操作）进行模块化调试	标准化指令语义降低认知负担
性能调优空间	钉死在固定指令序列，调优受限于微编码	可调tile shape/size/指令顺序/事件放置	Manual模式下保留底层控制能力
社区生态接入	自行对接PyTorch/TensorFlow，无统一接口	集成PyPTO、TileLang Ascend、PTOAS	统一ISA层为框架/工具链提供共同接口

从表格可以看到，PTO-ISA的核心价值在于找到了抽象层级和性能控制之间的平衡点。Auto模式面向快速验证，Manual模式面向极致的性能榨取。CPU模拟器在开发阶段降低了时间成本和硬件依赖，编译器的编译期约束检查在代码提交前就拦截了大量非法配置（如tile形状不对齐、数据类型不匹配等）。

PTO-ISA的指令分类与关键约束

PTO-ISA定义的90多条标准指令按功能可分为以下几类：逐元素运算（TADD、TMUL、TRELU等约30条），矩阵乘及其变体（TMATMUL、TGEMV等约8条），数据搬运和布局变换（TLOAD、TSTORE、TTRANS、TIMG2COL等约20条），轴归约与广播（TROWSUM、TCOLEXPAND等约20条），同步与资源绑定（TSYNC、SYNCALL、TASSIGN等约5条），以及复杂指令（TPRINT、TSORT32、TRANDOM等约10条）。

这些指令遵循一组通用的约束规则。Tile的容量形状在编译期固定，有效区域可以静态指定或运行时通过GetValidRow()/GetValidCol()查询。tile的布局支持两层嵌套：外层的基础布局（BLayout：行主序或列主序）和内层的分形/盒化布局（SLayout：NoneBox、RowMajor、ColMajor）。基块大小SFractalSize默认为512字节（用于A/B操作数tile）或1024字节（用于累加器tile）。这些约束通过static_assert在编译期强制检查：

// 编译期约束检查（示例性质）
// 未盒化RowMajor Tile: Cols * sizeof(Element) 必须是32字节的整数倍
static_assert(Cols_ * sizeof(Element_) % TileConfig::alignedSize == 0,
    "未盒化RowMajor Tile的列宽必须对齐到32字节");

// 盒化Tile的形状必须与基块维度兼容
static_assert(SLayout_ == pto::SLayout::NoneBox ||
    (Rows_ % baseTileRows == 0 && Cols_ % baseTileCols == 0),
    "盒化Tile的行列数必须为基块维度的整数倍");

这段代码展示了PTO Tile的编译期约束检查逻辑。整数倍约束防止了非对齐访问——例如fp32类型下，基块16x8占512字节，如果tile的行数不是16的倍数，盒化布局就无法完整填充基块。

硬件上的矩阵计算单元和DMA引擎要求数据以固定粒度对齐访问。非对齐访问要么触发"修复路径"（fixup path）导致性能骤降，要么直接触发硬件异常。编译期强制检查确保不合法或不高效的配置在编译阶段就被拦截，避免在NPU上运行时才暴露。

PTO-ISA还定义了专门用于NPU间通信的扩展指令集，覆盖点对点数据传输、信号同步和集合通信三类能力。这些通信原语延续了与计算指令一致的tile级抽象和跨平台设计，可通过驱动多种数据搬移硬件引擎（DMA、UB等），实现"计算与通信深度融合"的kernel模式——例如在GEMM计算的同时，通过TGET_ASYNC指令从远端NPU异步读取数据。

结尾

PTO-ISA为昇腾NPU的自定义算子开发提供了一个中间表示层。它将tile形状、有效区域、布局修饰符和同步语义封装为结构化的指令约定，让编译器在不同代际芯片之间建立统一的编译目标。Auto模式适合快速验证算法逻辑，Manual模式保留了对tile放置、同步点和指令顺序的直接控制。CPU模拟器在开发阶段提供了低延迟的验证途径。90多条标准指令覆盖了算子开发中的主要计算和搬运场景。理解PTO-ISA的这些概念，有助于开发者更清楚自己的C++代码在编译链路的每个阶段发生了什么，以及哪些约束是硬件固有的、哪些是抽象层的设计选择。

https://atomgit.com/cann/pto-isa