BarnaCore 性能网格

此页面上的每个构造函数地址、new 大小、延迟数组存储、资源网格单元和访问器读取路径都是从 libtpu-0.0.40-cp314 轮中的 libtpu.so 中读取字节(构建 ID 89edbbe81c5b328a958fe628a9f2207d)。二进制文件并未被剥离——每个符号都是经过分解的 C++ 名称。 .text/.rodata VMA == 文件偏移量； .data.rel.ro VMA - 0x200000 == 文件偏移量。所有地址都是VMA。其他版本有所不同。

摘要

xla::pufferfish::PufferfishBarnaCorePerformance 是 BarnaCore 的成本模型网格——Pufferfish (TPU v4) 是最后一代发布的传统嵌入加速器(请参阅退休证明)。它是河豚延迟表的变体 1 一半：LatencyTablePufferfish 定价为 std::variant<PufferfishPerformance, PufferfishBarnaCorePerformance>，其中变体 0 是密集的 TensorCore 网格(336×20，记录在 performance-pf 上)，变体 1 是此处记录的嵌入引擎网格。两者是通过同一个std::variant访客到达的； LLO 操作码通过 GetPufferfishInstruction 打包到其返回中的高 16 变体标签落在其中一个或另一个中。此页面是 BarnaCore 特定的对应于每代 performance-* 系列的页面 - 整个成本模型中最窄的网格。

该对象与每个较新的 Performance 具有相同的双数组形状(performance-overview 上框架的布局)：由 GetLatency(instr) 读取的平面 int32 latency[134] 堆数组，以及由 GetLatency(instr) 读取的二维 Instruction × Resource 占用网格GetResourceUsage(instr, res)。 BarnaCore 的独特之处在于其形状：延迟数组只有 134 个条目(相对于 TensorCore 的 336 个条目)，资源网格为 134 行 × 恰好一列——单个 EUP/先验结构危险单元。 TensorCore 变体 0 网格的宽度为 20 列(Viperfish 为 28，Ghostlite 31)，而 BarnaCore 则跟踪一种资源。嵌入引擎没有 MXU、没有转置、没有排列、没有跨通道归约：调度程序必须序列化的唯一操作内端口是扩展一元管道，并且网格通过在 6 个先验行上保留列 0 来表示这一点，而不是在其他地方。

该页面记录了三个结构，每个结构都从构造函数 PufferfishBarnaCorePerformanceC1 @0x1c8c38c0 逐个存储地恢复： 134 项延迟数组(按频带的值分布，以及其高延迟行处的命名原语)； 134×1资源网格(其中6行保留单个EUP列，以及硬编码列索引的读取路径)； 每代 EUP 延迟块 — 6 周期超越频带 (idx 0x77..0x7c)，即 BarnaCore EUP，比 TensorCore 变体 0 EUP (7) 便宜一个周期，并且比 Ghostlite (13/14) 便宜得多。通过 GetPufferfishInstruction 提供网格行的 13 个 LLO 分类原语与 bcs-scalar-isa 上的操作名称交叉链接。

重新实现，合约为：

两数组对象布局：一个 int32 latency[134] 堆数组(new 0x218，memset 0xff 然后完全覆盖)加上 1 宽 std::vector<int> 行的 134 行网格(new 0xC90，每行) new 4，默认 {0})，具有精确的构造函数 new 大小和字段偏移量。
延迟值分布：直方图 {0:1, 1:101, 2:21, 3:2, 4:2, 6:6, 12:1} = 134，指定行 —sync/wait/pop = 1，SyncDoneRead = 3，EUP 块 = 6，VectorStore = 12。
134×1资源网格：单个EUP单元列，仅由6个EUP超越行(idx 0x77..0x7c)保留(=1)；每隔一行的单个单元格保持 {0}。
读取路径：GetLatency = latency[instr]，具有一次绑定检查； GetResourceUsage = grid[instr].data[res]，具有两个边界检查和一个 24 字节(3-qword)行跨度；变体 1 访问者将 instr 读取为 uint8 字节并硬编码 res = 0。
变体 1 调度：BarnaCore LLO 操作码如何通过 GetPufferfishInstruction(高 16 变体标记 = 1)和 std::variant 访问者到达此网格 - 以及为什么 20 个高级嵌入操作永远不会这样做。


类别	`xla::pufferfish::PufferfishBarnaCorePerformance`(非多态值类型，0x30 B)
构造函数	`PufferfishBarnaCorePerformanceC1Ev` `@0x1c8c38c0`
延迟阵列	`new 0x218` = 536 B = 134 `int32`； `memset(_, 0xff, 536)` 然后将134全部覆盖
资源网格	`new 0xC90` = 3216 B = 134行×24 B (`std::vector<int>`);每行 `new 4` = 1 `int32`，默认 `{0}`
读取路径	`GetLatency` `@0x1c8c47e0`; `GetResourceUsage` `@0x1c8c4800`
网格形状	134 行(`Instruction`，计数 `0x86`)× 1 列(`Resource` = EUP 单位)； 6 个有人居住的单元格
EUP 块	延迟 idx `0x77..0x7c` = 6 (×6);保留资源第 0 列的唯一行 (`=1`)
最高延迟	idx `0x85` (`kBarnaCoreVectorStore`) = 12 — 嵌入行 HBM 写入
分类器	`GetPufferfishInstruction` `@0x1c8a1fe0`(变体标记；高 16 = 1 → 此网格)
变体 1 访客	`__dispatcher<1ul>::__dispatch<…ResourceUsageFromInstruction>` `@0x1c8a31a0`(读取 `uint8` 指令、`res = 0`)
单身人士	`pf_shared` `@0x22579a10` (TensorCore)、`pf_bc_shared` `@0x22579a20` (BarnaCore)
资源计数进展	BarnaCore 1 → PF-TC 20 → VF 28 → GL/GF 31
信心	已确认(反编译锚定，存储计数完整性)，除非行另有说明

注意 — 此页面是 BarnaCore 性能网格 — 成本模型读取的每条指令的延迟和资源数组。操作码 → Instruction-序数分类器(13 个 LLO 分类原语、20 个通道降低的嵌入操作)及其操作类名称位于 bcs-scalar-isa 上；所有代(PF 7 / VF 6 / GL 13-14)的每代 EUP 延迟整数以及 eup-per-gen-integers 上的延迟↔保留正交性。此页面固定 BarnaCore 编号及其布局。

对象：两个堆数组

用途

PufferfishBarnaCorePerformance 是一个值对象，保存两个堆分配及其边界 - 一个 SchedMachineModel 实例的 libtpu 模拟，但用于嵌入引擎而不是密集数据路径。构造函数内联构建两个数组；它后面没有.td表。恢复成本模型正是恢复构造函数存储的内容，这就是该页面逐个存储的内容。

这两个阵列回答两个不同的调度程序问题。 latency[instr] 是数据依赖边缘权重——消费者必须跟踪指令 instr 生产者的最小捆绑。 grid[instr][res] 是资源占用 - 多少个周期指令 instr 持有微管道端口 res，馈入捆绑打包器的 MaxResourceCycles 缩减。两者由不同的访问器从不同的数组中读取，并且永远不会相乘；正交性是数组级别的结构性(参见 eup-per-gen-integers)。

布局

text

PufferfishBarnaCorePerformance  (0x30 bytes; field offsets in qwords)
  [+0x00]  latency_ptr   -> int32 latency[134]      (new 0x218 = 536 B)
  [+0x08]  latency_count = 134   (0x86)             // GetLatency bound
  [+0x10]  latency_cap   = 134                      // capacity mirror
  [+0x18]  grid_ptr      -> std::vector<int> rows[134]   (new 0xC90 = 3216 B = 134 × 24)
  [+0x20]  grid_count    = 134   (0x86)             // GetResourceUsage outer bound
  [+0x28]  grid_cap      = 134
  each grid row: { data_ptr -> int32[1], size=1, cap=1 }   // new 4 = 1 int, default {0}

行计数 134 由 new 0x218 (536 ÷ 4 = 134) 固定，并再确认三次：[+0x08]=[+0x10]=134 用于延迟数组，[+0x20]=[+0x28]=134 用于网格，以及每行分配循环 for (i=16; i!=3232; i+=24)迭代 (3232−16)/24 = 134 次。重新实现者必须将两个数组的大小精确设置为 134(BarnaCorePerformance::Instruction 基数)并将每个网格行的宽度设置为 1。

算法

function PufferfishBarnaCorePerformanceC1(this):              // 0x1c8c38c0
    // --- latency array: 134 int32, sentinel then overwrite ---
    this[0]    = new(0x218)                  // 536 B = 134 int32
    this[+2]   = 134                          // capacity mirror
    memset(this[0], 0xff, 536)                // every slot = 0xffffffff sentinel
    this[+1]   = 134                          // latency_count (GetLatency bound)

    // --- resource grid: 134 rows of 1-wide vector<int>, default {0} ---
    grid = new(0xC90)                         // 3216 B = 134 × 24 (vector<int> header)
    this[+3]   = grid
    this[+5]   = 134
    for (i = 16; i != 3232; i += 24):         // 134 rows; i offsets the row's {ptr,size,cap}
        row = new(4)                          // 1 int32
        grid[i-16] = row                      // row.data
        grid[i]    = 1                         // row.cap
        *row       = 0                         // default cell value {0}
        grid[i-8]  = 1                         // row.size
    this[+4]   = 134                          // grid_count (GetResourceUsage outer bound)

    // --- fill latency[]: bound-checked, sequential idx 0..0x85 ---
    latency[0x00] = 1                          // (most ops default to 1)
    latency[0x01] = 0                          // no-op / null slot
    latency[0x02 .. 0x21] = 1
    latency[0x22] = 2
    ...                                        // see TABLE BC-L for the full distribution
    latency[0x77 .. 0x7c] = 6                  // the EUP/transcendental block
    // for each EUP row, ALSO reserve grid column 0:
    //   grid[0x77..0x7c].data[0] = 1          // the only resource cells written
    latency[0x85] = 12                         // kBarnaCoreVectorStore (HBM write)
    return this

每个存储都针对延迟数组的 this[+1](BUG() 溢出)进行绑定检查，并且 6 个 EUP 行网格存储针对 this[+4] 和每行大小进行绑定检查 - 证明转储完成的存储计数完整性(请参阅 § 存储计数完整性)。

功能图

符号	地址	证据
`PufferfishBarnaCorePerformance::PufferfishBarnaCorePerformance`(演员)	`0x1c8c38c0`	`new 0x218` 延迟，`new 0xC90` 网格，134 个商店
`PufferfishBarnaCorePerformance::GetLatency`	`0x1c8c47e0`	`latency[instr]`，绑定`[a1+8]`
`PufferfishBarnaCorePerformance::GetResourceUsage`	`0x1c8c4800`	`grid[instr].data[res]`，3-qword 步幅
`__dispatcher<1ul>::__dispatch<…ResourceUsageFromInstruction>`	`0x1c8a31a0`	变体-1 臂； `uint8`仪器，`res = 0`
`GetPufferfishInstruction`	`0x1c8a1fe0`	LLO 操作码 → `Instruction` + 高 16 变体标签
`GetSharedPufferfishBarnaCorePerformance::pf_bc_shared`	`0x22579a20`	变种-1 单例(防护 `@0x22579a28`)

读取路径

GetLatency — 一个数组，一个边界

GetLatency(instr) 是规范的 4 指令网格系列读取：根据 [+0x08] 处的计数对 instr 进行边界检查，然后返回 latency[instr]。它与 TensorCore (@0x1c8c3860)、Viperfish 和 Ghostlite GetLatency 的字节相同 - 只是它读取的数组不同。

function GetLatency(this, instr):              // 0x1c8c47e0
    if (this[+1] <= instr):  BUG()             // bound: latency_count
    return latency_ptr[instr]                   // int32, 4-byte indexed

**QUIRK — instr 在这里是 uint8，在 TensorCore 端是 uint16。**variant-1 调度程序将 BarnaCore Instruction 读取为单个字节 (movzx ...,BYTE)，因为 BarnaCore 枚举 ≤ 134 个值，适合 8 位； TensorCore 变体 0 调度程序读取 16 位 WORD 的 336 值枚举。重新实现者在错误的臂上读取错误的宽度将会错误地索引数组。

GetResourceUsage — 网格查找、两个边界、硬编码列

GetResourceUsage(instr, res) 遍历二维网格：针对 [+0x20] 处的外部计数对 instr 进行边界检查，计算 24 字节(3-qword)行步长，针对该行的 size 进行边界检查 res，然后返回grid[instr].data[res]。

function GetResourceUsage(this, instr, res):    // 0x1c8c4800
    if (this[+0x20] <= instr):  BUG()           // outer bound: grid_count
    grid = this[+0x18]
    row  = grid + 24*instr                       // 3 qwords per row: {data, size, cap}
    if (row.size <= res):  BUG()                 // inner bound: row width (= 1)
    return row.data[res]                         // int32, 4-byte indexed

注意 — 变体 1 访问者硬编码 res = 0。 std::variant 调度程序 __dispatcher<1ul>::__dispatch<…ResourceUsageFromInstruction> (@0x1c8a31a0) 调用 GetResourceUsage(perf, *instr_byte, 0) — 第三个参数是文字 0。因为 BarnaCore Resource 枚举正好是一宽，所以不需要其他列；成本模型仅查询单个 EUP 单元。 (访问者在发送之前还会保护 BarnaCore 臂的标签 variant_index == 2。)BarnaCore 根本没有 kResources / GetResources 符号 - 与 Ghostlite 的 kResources @0xb43cdc4 (31 个条目)不同 - 因为 1 宽枚举不需要排列表。

134 条目延迟阵列

用途

延迟数组是每个 BarnaCore Instruction 的数据依赖深度。它以单周期标量和廉价向量运算为主；唯一值得重新实现者注意的区域是下面的一小组非 1 行。完整数组有 134 个条目，但只有 33 个包含非 1 值，因此该表描述的是 bands，而不是所有 134 行。

TABLE BC-L — 非默认延迟行

134个条目全部写入(前导memset 0xff被完全覆盖)；下面未列出的每一行都是 1。 Instr idx 是 BarnaCorePerformance::Instruction 序数；数组中的字节偏移量 = idx × 4。 “原始”列仅在 GetPufferfishInstruction 将 LLO 操作码分类到其上的情况下命名行(参见 bcs-scalar-isa 表 B)；未命名行是通过通道发射器而不是 LLO 分类器到达的通道向量 ALU 操作。

仪器	延迟	原语/带
`0x01`	0	无操作/空插槽
`0x22`	2	通道向量二进制/比较 ALU
`0x33..0x38`	2 (×6)	通道向量二进制/比较组
`0x3a, 0x3b`	4 (×2)	中等成本矢量包/选择频段
`0x3d`	3	`kBarnaCoreScalarSyncDoneRead`(同步完成读取)
`0x3f`	3	(矢量运算)
`0x41, 0x42`	2 (×2)	(向量二进制/比较)
`0x4c`	2	(矢量运算)
`0x50`	2	(矢量运算)
`0x5e..0x63`	2 (×6)	通道向量二进制/比较组
`0x66`	2	(矢量运算)
`0x77..0x7c`	6 (×6)	EUP/先验块 — 保留资源网格的唯一行
`0x7d, 0x7e`	2 (×2)	(矢量运算)
`0x82`	2	(矢量运算)
`0x85`	12	`kBarnaCoreVectorStore` — 嵌入行 HBM 写入

直方图(来自构造函数的字节精确)：{0: 1, 1: 101, 2: 21, 3: 2, 4: 2, 6: 6, 12: 1} = 134。

解读

形状是一张表中的嵌入引擎。 134 个操作中的 101 个是单周期 — 标量同步/等待/弹出/移动原语和廉价的通道向量 ALU 操作，即嵌入内核指令组合的大部分。 21 是双周期 — 通道向量二进制/比较/打包组(连续频带 0x33..0x38 和 0x5e..0x63 是其中的 12 个)。 6 周期频带 (0x77..0x7c) 是 EUP，BarnaCore 拥有的最深的计算管道。单个 12 周期行(0x85、kBarnaCoreVectorStore) 是整个模型中最高的延迟 - 嵌入行存储回 HBM 端内存，该操作定义嵌入聚集的关键路径。

QUIRK — 没有 matmul/transpose band。 TensorCorevariant-0 数组(336 个条目)具有深 MXU band(matmul ≈ 83/101，transpose ≈ 126)。 BarnaCore 阵列最高为 12，因为嵌入引擎没有 MXU，也没有转置单元；它所做的广泛工作(聚集、分散、稀疏减少)被降低为上面的廉价原语，而不是作为单个深度操作定价(分类器中的 20 个高级操作 LogFatal - 请参阅 bcs-scalar-isa)。期望此数组中有 matmul 行的重新实现是错误的变体。

134×1资源网格

用途

网格是结构风险模型：每条指令占用每个微流水线端口多少个周期。对于 BarnaCore 来说，只有一个端口——EUP(扩展一元管道)超越单元。因此，网格为单列 134 行，并且只有 6 个 EUP 超越行写入非零单元格。其他所有指令均不包含跟踪资源；其单个单元保持在循环默认值 {0}。

TABLE BC-R — 单一资源列

网格分配为 134 行，每行一个宽度为 1 的 std::vector<int>，默认初始化为 {0}。构造函数在 EUP 行上准确写入 6 个单元格——全部为 0 列。行r的数据位于grid_base + r × 24； EUP 行位于偏移量 2856、2880、2904、2928、2952、2976 (= 0x77..0x7c × 24) 处，每个存储都受到每行大小检查的保护。

资源栏	填充行	值	乘员
`r0`(EUP单元)	`0x77..0x7c`(6 节电池)	1	6个EUP超越各保留EUP单元1个周期
`r0`	所有其他 128 行	0	无履带结构危险

解读

单列就是整个故事：BarnaCore 成本模型跟踪的唯一结构性危险是 EUP。比较整个网格系列的资源计数进展(从每代的 kResources 和网格宽度读取 - 请参阅 resource-enum)：

网格	资源栏目	他们跟踪什么
PufferfishBarnaCore(变体 1)	1	仅 EUP 单元
河豚 TensorCore(变体 0)	20	MXU matmul/matprep/transpose/permute/reduce/CCF/RNG 微管道端口
毒蛇鱼	28	+ 更宽的 MXU 和 Xlu 端口
Ghostlite (v6e)	31	+ v6e 微管道扩展

嵌入引擎的资源模型比密集 TensorCore 的资源模型窄一个数量级，因为它没有密集的微管道：没有脉动 MXU、没有转置锁存器、没有跨通道排列。它所拥有的能够阻止连续问题的一个管道是先验的 EUP，因此这是捆绑包装器的 MaxResourceCycles 缩减为 BarnaCore 捆绑咨询的一个单元。

GOTCHA — 资源单元 (=1) 是每次推送占用，而不是 EUP 延迟。 0x77..0x7c 行携带延迟 6(表 BC-L)和资源单元 1(表 BC-R)。它们是针对两个不同问题从两个不同数组读取的两个不同数字：latency-6 是消费者必须等待的推送→弹出数据依赖深度； Resource-1 是 EUP 端口保留的捆绑数量(背对背推送间距)。调度程序将它们组合为 max(latency-deadline, resource-availability)，而不是作为产品。每个世代都具有相同的正交性 - 请参阅 eup-per-gen-integers。 (BarnaCore EUP 的问题间距标量 VectorEupReservationCycles 是否与此每次推送单元 1 不同，并未单独隔离 — 低置信度，特别针对 BarnaCore 的背对背间距访问器。)

每代 EUP 延迟块

用途

idx 0x77..0x7c 的 6 周期频带是 BarnaCore EUP — 六通道超越成本模型价格。它是跨代 EUP 延迟进程中的 BarnaCore 条目，也是该网格作为单独变体存在的原因：嵌入引擎具有其“自己的”超越延迟，与密集的 TensorCore 不同。

六大功能及跨代比较

6 条目宽度与 BarnaCore 通道的六功能超越块匹配：VectorReciprocalSquareRoot (rsqrt)、VectorPow2 (2^x)、VectorLog2、VectorTanh、VectorReciprocal (1/x) 和VectorRelux(ReLU-带上夹)。这些通过通道发射器的 MigrateInstruction<Alu0_VectorX, Alu1_VectorX> 模板而不是 GetPufferfishInstruction 到达 Instruction 枚举，因此块是字节确认的(6 个条目，延迟 6，唯一的 6 个 EUP 资源单元)，但块内序数排列 - 0x77..0x7c 是 Tanh vs Pow2 vs Log2 vs Rsqrt vs Recip vs Relux — 未固定(每个序数映射上的低置信度；块身份已确认)。

QUIRK — BarnaCore 将 pushErf 替换为 Relux。 TensorCore 变体 0 EUP 块是 {rsqrt, pow2, log2, tanh, recip, pushErf}； BarnaCore 的是 {rsqrt, pow2, log2, tanh, recip, relux}。嵌入加速器在密集引擎在 erf 推送上花费的插槽中对 ReLU-clamp 超越(嵌入激活原语)进行定价。将 TensorCore 块镜像到 BarnaCore 的重新实现将是一个功能错误。

Gen(网格)	EUP推送延迟	源码	数据类型拆分
PufferfishBarnaCore(变体 1)	6	`latency[0x77..0x7c]`(本页)	制服
河豚 TensorCore(变体 0)	7	`latency[0x67..0x6c]`	制服
毒蛇鱼	6	`latency[0xcc..0xd2]`	制服
Ghostlite	13 (F32) / 14 (BF16)	`latency[0x106..0x118]`	每个数据类型
EUP 流行音乐(所有世代)	1	流行序数	—

BarnaCore EUP 比 Pufferfish TensorCore EUP 便宜一个周期(6 比 7)——结构上与精简的 134 项嵌入 ISA 一致——并且比 Ghostlite 的 13/14 便宜得多，这反映了 Ghostlite 更深的 FIFO 缓冲超越单元。全系列的每代 EUP 整数、F32/BF16 拆分原理以及延迟↔预留分解均归 eup-per-gen-integers 所有；此页面提供 BarnaCore 行。

操作码如何到达该网格

变体调度

BarnaCore LLO 操作码通过为每个河豚指令定价的相同 std::variant<PufferfishPerformance, PufferfishBarnaCorePerformance> 机器到达 PufferfishBarnaCorePerformance。 GetPufferfishInstruction @0x1c8a1fe0 对 LLO 操作码(跳转表 @0xb43927c、idx = opcode − 2)进行分类，并将 low16 = Instruction、high16 = variant tag 打包到其返回中。 LatencyTablePufferfish::LatencyBetweenInternal 提取变体标签 (shr ...,0x10) 并索引 2 臂函数指针表：标签 0 → TensorCore 网格，标签 1 → 此 BarnaCore 网格 (pf_bc_shared @0x22579a20)。

text

  LLO opcode (0x1ac..0x1cc for kBarnaCore*)
|
        v
  GetPufferfishInstruction  @0x1c8a1fe0   -> { low16: Instruction, high16: variant }
|                                          variant == 1 for the 13 BarnaCore primitives
        v
  std::variant visitor  (high16 selects the arm)
|
        +-- tag 0 -> PufferfishPerformance         (TensorCore grid, 336x20)
        +-- tag 1 -> PufferfishBarnaCorePerformance (this grid, 134x1)
|
                          +-- GetLatency(instr)             -> latency[instr]
                          +-- GetResourceUsage(instr, 0)    -> grid[instr].data[0]

哪些操作码到达它

确切地说 13 个 LLO 操作码 路由到变体 1 — 标量同步/等待/弹出和向量加载/存储原语 0x1ac..0x1cc(bcs-scalar-isa 表 B 上的 C 分类行)。它们的 Instruction 序号(0x04、0x05..0x0b、0x3d、0x3e、0x84、0x85)直接索引延迟数组：例如kBarnaCoreScalarSyncDoneRead→0x3d(延迟3)，kBarnaCoreVectorStore→0x85(延迟12)。其他 20 kBarnaCore* 操作码(聚集/分散/稀疏减少/FSM/远程缓冲区)不分类到此网格中 - 它们在 GetPufferfishInstruction 中的 LogFatal (“Pufferfish 不支持：…河豚不支持。”)并通过通道/序列器发射器降低到 13 个价格基元。 EUP 块行 (0x77..0x7c) 和 2 周期向量组同样是通过通道发射器的 MigrateInstruction 模板而不是 LLO 分类器到达的 - 它们在发射它们返回的通道向量 ALU 操作时定价。

注意 - 20 个高级操作在此网格中没有独立延迟。 它们的成本是它们扩展成的原语的运行时动态总和(LocalGather ≈ 10 标量 ALU + 2 DMA + 同步；GlobalScatterGradients ≈ 分区数学 + 远程 DMA 的列循环)。成本模型必须遍历 BcsLloEmitter 扩展 (bcs-scalar-isa)，而不是查找该数组中的高级操作 - 这正是直接分类器中这 20 个操作码 LogFatal 的原因。

存储计数完整性 {#store-count-integrity}

通过网格系列中使用的相同存储计数方法可证明转储是完整的。构造函数准确地发出布局所需的存储，没有第三个存储习惯用法(没有 push_back，没有向量增长 - 唯一的分配是两个 new + 每行 new 循环)：

商店类	计数
延迟数组存储	134
网格EUP排店	6
每行默认初始化存储	134

134 个延迟存储与直方图 {0:1, 1:101, 2:21, 3:2, 4:2, 6:6, 12:1} 完全一致； 6 个网格存储都是 EUP 行上的第 0 列； 134 行默认存储是循环体。每个存储都针对计数字段进行边界检查(溢出时为 BUG())，因此数组维度 (134 / 134×1) 通过构造函数自己的检查是不言而喻的。针对反编译进行了字节精确验证的 Spot 单元：latency[0x22]=2(偏移量 136)、latency[0x3a]=4(偏移量 232)、latency[0x3d]=3(偏移量 244)、latency[0x77]=6(偏移量 476)、latency[0x85]=12(偏移量 532)和grid[0x77].data[0]=1(行偏移 2856)。

注意事项

variant标签选择数组；在索引之前阅读它。 BarnaCore 操作码和 TensorCore 操作码可以共享数字 Instruction 值；只有 GetPufferfishInstruction 中的高 16 变量标签可以消除要索引的 134 或 336 条目数组的歧义。删除变体标签的重新实现将索引错误的网格。
**BarnaCore Instruction 是 uint8； TensorCore 是 uint16。**variant-1 调度程序读取单个字节 (@0x1c8a31a0)。在 BarnaCore 臂上读取 WORD 会偏离预期索引。
资源网格的宽度为 1，第 0 列是唯一的列。 GetResourceUsage 始终从变量 1 访问者中使用 res = 0 进行调用。 BarnaCore 没有 kResources 排列表；不要寻找一个。
6 周期 EUP 块的带内序数图置信度较低。 该块是字节确认的(6 个条目，延迟 6，唯一的 EUP 资源单元，身份 = 6 通道超越，包括 Relux)，但 0x77..0x7c 内的精确序数到函数排列(Tanh vs Pow2 vs ...)和 2 周期向量组的每个序数名称(0x33..0x38、0x5e..0x63)未固定 - 它们是通过通道发射器的 MigrateInstruction 模板到达的，该模板没有可从中读取序数的跳转表分类器。
延迟 6 EUP 单元和资源 1 EUP 单元是不同的数字。 延迟 6 是推送→弹出数据截止时间；资源 1 是 EUP 端口保持(发出间隔)。它们生活在不同的阵列中，并组成一个 max，而不是一个产品。 BarnaCore EUP 问题间隔标量是否与 1 的单元相匹配(PF TensorCore 使用 2 = 半速率)没有单独隔离 - 低置信度。
Pufferfish 是唯一发布此变体的一代。 从 Viperfish 开始，BarnaCore 已退役 (退休证明)；后来的 Performance 对象都没有 BarnaCore 臂。以 v5+ 为目标的重新实现根本不需要这个网格。

名称	关系
`PufferfishPerformance`(变体 0)	TensorCore网格与`LatencyTablePufferfish`价格相同，336×20 — `performance-pf`
`LatencyTablePufferfish`	通过变体标签选择此网格的 `std::variant<TensorCore, BarnaCore>` 支架
`GetPufferfishInstruction` `@0x1c8a1fe0`	LLO 操作码 → `Instruction` + 变体标签分类器
`PufferfishBarnaCoreChannelEmitter`	发出支持 6 周期块的通道向量 ALU 操作(包括 6 个 EUP 超越)

交叉引用

BCS Scalar0/Scalar1 ISA — 13 个 LLO 分类基元，用于提供此网格的行、它们的操作类名称以及解释 LogFatal 行的 20→13 嵌入操作降低。
BarnaCore 概述 — BarnaCore 是什么、BCS/BCAH 个性划分以及河豚嵌入引擎在管道中的位置。
退休证明 - 为什么河豚是具有此网格的最后一代；狭窄的一列资源模型是功能差距论点的一部分。
合并 ALU 位布局 — EUP 块和 2 周期向量行所属的通道向量/标量 ALU 谱系。
性能：PF — TensorCore 变体 0 网格 (336×20)；此页面是其对应的variant-1页面，通过同一访问者到达。
性能：GL (GhPerf 476×31) — 一个后来的、更宽的网格 (476×31)，用于对比形状和资源计数。
性能概述 — 所有网格家族通用的共享双阵列网格布局和 GetResourceUsage 读取路径。
EUP 每代延迟整数 — 跨代进程中的 BarnaCore EUP-6 (PF 7 / VF 6 / GL 13-14) 和延迟↔保留正交性。
资源枚举 — 成本模型 Resource 枚举和每代槽数级数(BarnaCore 1 → PF-TC 20 → VF 28 → GL/GF 31)。
二进制： extracted/libtpu-0.0.40-cp314-cp314-manylinux_2_31_x86_64/libtpu/libtpu.so(构建 ID 89edbbe81c5b328a958fe628a9f2207d)
索引条目： 第九部分 — SparseCore 和 BarnaCore / BarnaCore(旧版 v2–v4) — 返回索引

BarnaCore 性能网格 ​

摘要 ​

对象：两个堆数组 ​

用途 ​

布局 ​

算法 ​

功能图 ​

读取路径 ​

GetLatency — 一个数组，一个边界 ​

GetResourceUsage — 网格查找、两个边界、硬编码列 ​

134 条目延迟阵列 ​

用途 ​

TABLE BC-L — 非默认延迟行 ​

解读 ​

134×1资源网格 ​

用途 ​

TABLE BC-R — 单一资源列 ​

解读 ​

每代 EUP 延迟块 ​

用途 ​

六大功能及跨代比较 ​

操作码如何到达该网格 ​

变体调度 ​

哪些操作码到达它 ​

存储计数完整性 {#store-count-integrity} ​

注意事项 ​

相关组件 ​

交叉引用 ​

BarnaCore 性能网格

摘要

对象：两个堆数组

用途

布局

算法

功能图

读取路径

GetLatency — 一个数组，一个边界

GetResourceUsage — 网格查找、两个边界、硬编码列

134 条目延迟阵列

用途

TABLE BC-L — 非默认延迟行

解读

134×1资源网格

用途

TABLE BC-R — 单一资源列

解读

每代 EUP 延迟块

用途

六大功能及跨代比较

操作码如何到达该网格

变体调度

哪些操作码到达它

存储计数完整性 {#store-count-integrity}

注意事项

相关组件

交叉引用