一个 Ascend C kernel 写好后，要在昇腾 NPU 上执行，需要经过两道编译：第一道，昇腾编译器把 Ascend C 翻译成 PTO（Parallel Tensor Orchestration）虚拟指令；第二道，NPU 固件在运行时把 PTO 虚拟指令翻译成 AI Core 的具体硬件指令。

PTO-ISA 定义的就是中间这一层的指令集规范。它不绑定具体的 NPU 硬件代际——Ascend 910 和 Ascend 950PR 都跑同一套 PTO 指令，固件负责把 PTO 映射到各自的硬件实现。这是「写一次，跨NPU代际运行」的关键。

PTO 指令集的三类指令

指令类	数量	功能	对应硬件
计算指令	32+	MMAD、VMAC、VEXP、VLOG…	Cube/Vector 单元
数据搬运指令	12+	LOAD、STORE、DMA_COPY、PREFETCH	SDMA/L1 缓存
控制指令	8+	SYNC、BARRIER、LOOP、COND	调度器

一个简化版的 MatMul kernel 对应的 PTO 指令序列：

; PTO IR for simplified MatMul: C[M,N] += A[M,K] * B[K,N]
; M=256, N=256, K=256, tile=64

LOOP k_outer, K/64:               ; 外部循环：K 维度分块
    LOAD tile_a, A_ptr, {64, 64}  ; 从 HBM 加载 A[64,64] 到 L1
    LOAD tile_b, B_ptr, {64, 64}  ; 从 HBM 加载 B[64,64] 到 L1
    SYNC LOAD_DONE                 ; 等待数据到达
    
    MMAD C_local, tile_a, tile_b   ; Cube 单元计算 C += A × B
    SYNC COMPUTE_DONE
    
    STORE C_ptr, C_local, {64, 64} ; 写回 HBM
    SYNC STORE_DONE
    
    ADD A_ptr, A_ptr, 64*64*2      ; 推进 A、B 的 HBM 指针
    ADD B_ptr, B_ptr, 64*64*2
END_LOOP

每条 PTO 指令被固件展开为 1-N 条硬件指令。MMAD 在 Ascend 910 上被映射到 4 条硬指令（四次 16×16 的矩阵乘-加），在 Ascend 950PR 上可能映射到 1 条硬指令（硬件支持 64×64 的 MMAD 了）。

PTO 的融合重写：指令级优化

编译器在生成 PTO 时会做指令级重写——把多个独立的 PTO 指令融合成一条复合 PTO 指令。这是算子性能的关键：

; 优化前：独立的 LOAD + MMAD + STORE
LOAD tile_a, A_ptr, {64, 64}
LOAD tile_b, B_ptr, {64, 64}
SYNC LOAD_DONE
MMAD C_local, tile_a, tile_b
SYNC COMPUTE_DONE
STORE C_ptr, C_local, {64, 64}
SYNC STORE_DONE

; 优化后：融合成一条 FUSED_MMAD 指令
; LOAD 用双缓冲：加载下一块数据时 MMAD 在算当前块
; STORE 也一样：MMAD 在算时，上一块的结果被 SDMA 搬走
FUSED_MMAD C_ptr, A_ptr, B_ptr, {
    tile={64, 64, 64},
    double_buffer=true,
    async_store=true
}

融合后的 FUSED_MMAD 一条指令覆盖了原来的 7 条指令。硬件上：Cube 单元算 64×64×64 的 MMAD 时，SDMA 同时在搬数据——算力 100% 跑满，搬运也在同步走。延迟藏在双缓冲的 overlap 里。

踩坑一：LOAD 和 MMAD 的依赖分析失效

PTO 编译器用数据依赖分析来判断哪些 LOAD 可以和 MMAD 融合。如果 Ascend C kernel 里的指针别名分析不够精确，编译器保守地认为两个 LOAD 可能访问重叠的内存——不融合，性能直接掉 40%。

错误写法：

// Ascend C kernel：两个指针被编译器认为是可能重叠的
__aicore__ void kernel(GlobalTensor<float>& a, GlobalTensor<float>& b) {
    float* ptr1 = a.GetPtr();  // 从参数 a 获取
    float* ptr2 = a.GetPtr();  // 从同一个参数 a 获取
    
    // 编译器看到两个指针都指向 a → 可能重叠 → LOAD 不并行
    LocalTensor<float> t1(64);
    LocalTensor<float> t2(64);
    DataCopy(t1, ptr1, 64);   // LOAD 1
    DataCopy(t2, ptr2, 64);   // LOAD 2（等 LOAD 1 完成？保守是）
    
    // PTO 生成：LOAD t1 + SYNC → LOAD t2 + SYNC
    // 两条 LOAD 串行，没有融合
}

正确写法：用 __restrict__ 告诉编译器两个指针不重叠。

// 正确：用 __restrict__ 声明指针不重叠
__aicore__ void kernel(
    GlobalTensor<float>& __restrict__ a,
    GlobalTensor<float>& __restrict__ b
) {
    float* __restrict__ ptr1 = a.GetPtr();
    float* __restrict__ ptr2 = b.GetPtr();  // 不同参数
    
    LocalTensor<float> t1(64);
    LocalTensor<float> t2(64);
    DataCopy(t1, ptr1, 64);   // LOAD 1
    DataCopy(t2, ptr2, 64);   // LOAD 2（独立，可并行）

    // PTO 生成：FUSED_LOAD t1, t2（融合成一条）
    // 两个 LOAD 并行启动，SDMA 同时搬两路数据
}

性能差异：两条 LOAD 独立并行 → 融合成 FUSED_LOAD，数据搬运时间减半。在带宽敏感的 kernel 里（如 matmul），这是 30-40% 的性能差异。

踩坑二：STORE 的隐式同步点

PTO 编译器在 MMAD 和 STORE 之间自动插入 SYNC COMPUTE_DONE。但如果 kernel 在 MMAD 之后有别的不依赖结果的计算（比如处理下一块的 index 更新），这个隐式 SYNCC 是不必要的——它把流水线打断了。

错误写法：

// Ascend C kernel：MMAD 之后直接更新 index
// PTO 编译器插入了隐式 SYNC COMPUTE_DONE
MMAD(C_local, a_tile, b_tile);
// ← 自动插入 SYNC

// index 更新不依赖 C_local，不需要等 MMAD 完成
int next_offset = current_offset + tile_size;  // 不依赖 MMAD

DataCopy(C[offset], C_local, 64);
// 编译器又插入 SYNC（等 index 更新完成）

正确写法：先把不依赖结果的 index 更新提到 MMAD 之前。

// 正确：MMAD 之前算好所有 index
int next_offset = current_offset + tile_size;  // 不依赖上一个 MMAD

MMAD(C_local, a_tile, b_tile);
// ← 编译器自动插入 SYNC（现在只有一次，不影响 index）

DataCopy(C[current_offset], C_local, 64);
// 不需要再等 index

根因：PTO 编译器对 MMAD 后的第一个写操作（包括整数变量赋值）自动插 SYNC COMPUTE_DONE——它保守地认为后续操作可能依赖前面的计算。但实际上 index 更新是纯整数计算，完全不依赖浮点 MMAD 的结果。

踩坑三：虚指令的硬件退化路径

PTO 的 FUSED_MMAD 在某些硬件代际上不被原生支持——固件会把它退化（degrade）成多条基本 PTO 指令。退化后的指令序列有额外的 L1 容量需求，可能导致 L1 溢出。

场景：在 Ascend 910 上开发了用了 FUSED_MMAD 的 kernel。性能在 910 上很好。部署到 Ascend 950PR 时，固件把 FUSED_MMAD 映射到一条硬件指令（原生支持），L1 里的中间数据排布和 910 不同。kernel 里硬编码的 L1 usage 假设被打乱了。

正确做法：不和底层硬件绑定——在 kernel 代码里用 #ifdef 或运行时查询来适配 L1 容量：

// 查询当前 NPU 的 L1 大小
int l1_capacity = GetChipL1CacheSize();  // Ascend 910: 192KB
                                          // Ascend 950PR: 256KB

// 按 L1 容量动态算 tile size
int max_tile = (l1_capacity - reserve) / (3 * sizeof(float));
int Mb = min(M, max_tile);
int Nb = min(N, max_tile);
int Kb = min(K, max_tile / 2);

---

PTO-ISA 不是面向应用开发者的接口——写 kernel 的人看不到 PTO 指令。但理解 PTO 的作用，能解释为什么 kernel 性能在 910 和 950PR 上差一倍（FUSED_MMAD 被退化 vs 原生支持），为什么加一行 __restrict__ 能让 matmul 快 40%（LOAD 融合），为什么 index 更新放在 MMAD 之后会拖慢流水线（隐式 SYNC 打断）。

这些不是编译器 bug，是编译器保守策略和硬件代际差异的合理约束。PTO-ISA 文档提供了每种指令在不同硬件上的退化路径——看一遍退化路径，就知道怎么写 Ascend C kernel 能让三个代际的 NPU 都跑出峰值。