GXC 家族（Ghostlite, 6acc60406）

地址适用于 libtpu-0.0.40-cp314 wheel 中的 libtpu.so（build-id 89edbbe81c5b328a958fe628a9f2207d）。其他版本会有所不同。

摘要

GXC 是没有自有工厂的家族。二进制中不存在 TpuHalGxcHardwareFactory、TpuChipGxcDriverImpl，也不存在任何 TpuGxcDriver 符号。相反，GXC 的两个代号——Ghostlite（TpuVersion::kGhostlite = 4）和 6acc60406（k6acc60406 = 5）——由各自的 init 模块（glc 和 gfc）注册到共享的 tpu::TpuHalVxcHardwareFactory 中，并复用完整的 VXC HAL 产品链（TpuHalVxcHardwareImpl、TpuVxcDriver、V2 描述符）。在 HAL 对象层面，GXC 是 VXC 家族的成员。

让 GXC 成为一个独立家族的是它的驱动层子核心 ISA。Viperfish 的 ISA 位于 vxc::vfc/vxc::vlc 下，而 Ghostlite 和 6acc60406 各自在 asic_sw::driver::deepsea::gxc:: 下拥有自己的子核心命名空间：gxc::gfc（general fetch-core）和 gxc::glc（general load-core）。每个子核心都有自己的 isa 和 profiler 子命名空间，编解码器只绑定到其中之一，并且 LLVM subtarget（TPUGlcSubtarget、TPUGfcSubtarget）也是 GXC 专属的。因此，GXC 继承了 PXC 引入的 fetch/load 拆分，同时配套了自己的 ISA 世代——这是该二进制中最新的一代。

本页遵循 JXC、PXC 和 VXC 页面相同的语法，但有两个结构性注意点：“工厂绑定”一节指向 VXC 工厂（已在 VXC 页面完整覆盖），并且 Ghostlite↔glc、6acc60406↔gfc 的代号配对本身就是核心发现。

对于重新实现，契约是：

GXC 没有自有工厂或 HAL 产品——glc/gfc init 模块把 v4/v5 注册到 TpuHalVxcHardwareFactory；产品就是 VXC 产品。
gxc::gfc（fetch-core）/ gxc::glc（load-core）子命名空间各自拥有自己的 isa 和 profiler——这就是 GXC 虽然共享 VXC HAL 但仍构成一个家族的原因。
代号↔子核心配对：Ghostlite (v4) = glc，6acc60406 (v5) = gfc（已修正的映射，见提示框）。
具名与匿名编解码器的不对称：TpuCodecGhostlite 完整保留符号名；v5 编解码器被剥离符号。
共享的 GlGf bundle 编码器：ProgramProtoUtil::BundleCount（0x1e830e80）把 v4 和 v5 都路由到同一条 CreateEncoderGlGf 路径，因此 6acc60406 复用 Ghostlite 的编码器——这解释了尽管存在具名/匿名拆分，两个 gxc 子核心 ISA 命名空间的规模仍然接近。


自有工厂类	无——使用 `tpu::TpuHalVxcHardwareFactory`（vtable 0x21cabf70）
TpuVersions	kGhostlite (4), k6acc60406 (5)
Init 模块	`..._glc_hardware_impl` 0x213eb9e0 (v4), `..._gfc_hardware_impl` 0x213e9f60 (v5)
HAL impl 类	`TpuHalVxcHardwareImpl`（共享，216 B）——没有 GXC 专属 impl
子核心	`gxc::gfc`（general fetch-core），`gxc::glc`（general load-core）
自有 isa/profiler	按子核心划分：`gxc::{gfc,glc}::isa`，`gxc::{gfc,glc}::profiler`
DMA 引擎	`tpu::TpuVxcDriver`（与 VXC 共享）；DmaDescriptorV2

工厂绑定与注册

目的

GXC 的代号需要抵达一个 HAL 实现，但 GXC 没有工厂类来提供它。glc 和 gfc init 模块通过构造一个 TpuHalVxcHardwareFactory 实例并按各自的 TpuVersion 注册来解决这个问题。由此得到的 HAL 对象是 TpuHalVxcHardwareImpl——一个 VXC 产品。

入口点

text

google_init_module_tpu_hal_glc_hardware_impl (0x213eb9e0)   // Ghostlite
  └─ operator new(0x10) ; f[+8] = 4 ; f[+0] = VXC vtable 0x21cabf80
     TpuHalFactory::Register(kHardware, 4, f)

google_init_module_tpu_hal_gfc_hardware_impl (0x213e9f60)   // 6acc60406
  └─ operator new(0x10) ; f[+8] = 5 ; f[+0] = VXC vtable 0x21cabf80  (SAME vtable)
     TpuHalFactory::Register(kHardware, 5, f)
```text

### 算法

```c
function google_init_module_tpu_hal_glc_hardware_impl():   // 0x213eb9e0 (Ghostlite)
    f = operator_new(0x10)
    f[+8] = 4                               // kGhostlite (mov $0x4)
    f[+0] = &VxcFactory_vtable + 0x10        // VXC vtable 0x21cabf80 — NOT a GXC vtable
    TpuHalFactory::Register(kHardware, 4, unique_ptr(f))
    CHECK(s == OK)   // string 0x94A4A6F: make_unique<TpuHalVxcHardwareFactory>(kGhostlite)

// gfc module (0x213e9f60) is identical with version=5 (mov $0x5), CHECK 0x94A3EF5

怪癖—— CHECK 字符串精确证明了绑定：两者都传入 std::make_unique<tpu::TpuHalVxcHardwareFactory>(...)——这是 VXC 工厂，而不是 GXC 工厂。init 模块以 GXC 子核心（glc/gfc）命名，但它构造的类是 VXC。这就是为什么代号矩阵把 v4/v5 路由到 VXC 家族，而子核心分类把它们列在 GXC 下：这里 HAL 家族与驱动子命名空间是解耦的。

函数映射

函数	地址	作用
`google_init_module_tpu_hal_glc_hardware_impl`	0x213eb9e0	将 v4 注册进 VXC 工厂
`google_init_module_tpu_hal_gfc_hardware_impl`	0x213e9f60	将 v5 注册进 VXC 工厂
`xla_target_ghostlite`	0x213eeee0	编译器目标注册（v4）

工厂 vtable

GXC 没有工厂 vtable。v4 和 v5 完整使用位于 0x21cabf70 / vptr 0x21cabf80 的 VXC 工厂 vtable——slot、typeinfo、CreateImpl 等全部复用。完整的 5-slot 走查和 216 字节 impl 见 VXC 家族页面。在 HAL 对象层面，唯一对 GXC 可见的状态是存储在工厂 +8 并传入 impl +0x78 的 TpuVersion（4 或 5）。

注意—— 因为 GXC 复用 VXC CreateImpl（它从 work-queue 读取版本），所以构造时 Ghostlite HAL 对象和 Viperfish HAL 对象之间的唯一区别就是 TpuVersion 值。每个代号的行为会在更下层解析，即 TpuHalVxcCommonHelper::InitializeDrivers 中（VXC 页面记录的 cmp $5 / $4 / $3 switch）以及编解码器中。

子核心子命名空间清单

GXC 的故事发生在驱动层。asic_sw::driver::deepsea::gxc:: 正好有两个直接子命名空间——fetch/load-core 对——并且不同于 PXC 和 VXC，没有家族级 isa 或 profiler：GXC 的 ISA 和 profiler 完全位于子核心之下。

子命名空间	作用
`gxc::gfc`	general fetch-core——6acc60406 (v5) 子核心
`gxc::glc`	general load-core——Ghostlite (v4) 子核心
`gxc::gfc::isa`	v5 ISA（270K symbols）——例如 `TensorCoreBundleCompact`、SparseCore Tec codecs
`gxc::glc::isa`	v4 ISA（294K symbols）——例如 `TensorCoreBundleCompact`、SparseCore codecs
`gxc::gfc::profiler`	v5 profiler（48K symbols），带具名 `TraceEntry` 类（4781 token occ.）
`gxc::glc::profiler`	v4 profiler（29K symbols），带具名 `TraceEntry` 类（4590 token occ.）

注意—— 不存在家族级 gxc::isa（搜索 deepsea3gxc3isa 返回零）；ISA 位于比 PXC/VXC 更深一层的位置，在子核心下（gxc::gfc::isa、gxc::glc::isa，并有对应的 profiler 命名空间）。GXC 只在 HAL 对象层共享 VXC 家族（共同的工厂/impl）；ISA 层完全是 GXC 专属。
怪癖—— 命名配对不符合直觉，并且曾是文档化的 off-by-one 来源。Ghostlite (v4) 绑定到 gxc::glc（load-core），而 6acc60406 (v5) 绑定到 gxc::gfc（fetch-core）。编解码器走查在符号层面确认了这一点：TpuCodecGhostlite 只分派到 gxc::glc::isa + ghostlite::isa::EncoderGl*；匿名 v5 编解码器只分派到 gxc::gfc::isa。按二进制自身的命名轴（TpuVersionToExternalName @ 0x20b3a500），Ghostlite 显示为 "TPU v6 lite"（Cloud accelerator_type v6e），6acc60406 显示为 "TPU7x"（Cloud tpu7x）——整整相差一代。把 gfc 解读为“v6e fetch core”的重新实现会错一代。（这些世代的公开营销名称没有嵌入二进制，并且这里有意不引用——见 Marketing / Cloud Naming。）

工厂下方的构造链

目的

GXC 没有自己的构造链。Ghostlite 或 6acc60406 HAL 对象是一个 TpuHalVxcHardwareImpl，而 CreateAndInitializeChips 是位于 0x1d110f20 的 VXC 方法。GXC 专属工作发生在 helper 的按代号 switch 内，其中 chip-parts 版本（4 或 5）选择设备扫描器并校验 variant。

入口点

text

TpuHalVxcHardwareImpl::CreateAndInitializeChips (0x1d110f20)   ── shared VXC method
  └─ TpuHalVxcCommonHelper::InitializeDrivers (0x1d111a80)      ── per-codename switch
       ├─ case 4 (Ghostlite): validate variant; else "ghostlite unsupported variant " (0xa1d992b)
       ├─ case 5 (6acc60406): validate variant; else "6acc60406 unsupported variant " (0xa1d990c)
       └─ generic: asic_sw::deepsea::DeepseaDeviceScanner (0x1fba7a20)
```text

### 注意事项

switch 的 Ghostlite (v4) 和 6acc60406 (v5) 分支是拒绝式校验器：它们根据每个代号的允许列表确认 chip-parts `variant_name()`，并在遇到不受支持的 variant 时报错。不同于 Viperfish (v3) 分支，v4 和 v5 都不会构造代号专属设备扫描器——它们会落到共享的 `DeepseaDeviceScanner`。产品对象完整使用 VXC 的对象：`TpuChipVxcDriverImpl`（416 B）、296 字节的 `SyncFlagResources`，以及 `TpuCoreVxcDriverImpl`（800 B），它们都接收一个 `TpuVxcDriver*`。构造链细节见 [VXC 家族](vxc-family.md#construction-chain-below-the-factory)。

---

## 编译器目标与成本模型绑定

### 目的

虽然 HAL/driver 层与 VXC 共享，*编译器*层却是 GXC 专属的。每个 GXC 代号都会注册自己的 LLVM 风格编译器目标、自己的成本模型 cycle table，并且（对于 Ghostlite）还有自己的 LLO 到指令映射表。

### 函数映射

| 构件 | 地址 / 符号 | 代号 |
|---|---|---|
| `xla_target_ghostlite` | 0x213eeee0 (`mov edi,4`) | Ghostlite (v4) |
| `GlcCycleTable` vtable | `_ZTV` 0x21c20148 | Ghostlite (v4) |
| `GfcCycleTable` vtable | `_ZTV` 0x21c201c8 | 6acc60406 (v5) |
| `TPUGlcSubtarget` | predicate-regs @ 0x13c615c0 (16) | Ghostlite (v4) |
| `TPUGfcSubtarget` | predicate-regs @ 0x13c630e0 (16) | 6acc60406 (v5) |
| `GhostliteCodecMetadata` vtable | `_ZTV` 0x21d647a8 | Ghostlite (v4) |
| `xla::ghostlite::kLloOpcodeToGlcInstruction` | 0x4067dc8 (258 entries) | Ghostlite (v4) |

### 注意事项

v4 和 v5 之间的不对称在这里最明显。Ghostlite 有一个*具名*编译器目标 init（`xla_target_ghostlite`）、一个*具名* `GhostliteCodecMetadata`，以及一张具名 LLO 映射表；6acc60406 有成本模型 `GfcCycleTable`（具名），但没有 `xla_target_6acc60406` 符号，也没有具名 codec metadata——它的 codec metadata 是 `CodecMetadataRegistry` 中的一个匿名条目（singleton guard 0x22582fa0）。两个 subtarget 都报告 16 个 predicate register，因此 predicate-register 数量*不是*区分 v4/v5 的轴；bundle opcode/predicate 字段宽度才是（见下文“按代号区分”）。

> **注意——** GXC 成本模型位于编译器基命名空间下（`xla::jellyfish::GlcCycleTable` / `GfcCycleTable`），与 JXC 的 `JfCycleTable` 完全一样——这是又一个示例：世代专属的编译器状态挂在共享的 `xla::jellyfish::` 基命名空间下，而驱动状态位于 `asic_sw::driver::deepsea::gxc::` 下。这两棵树记录在[子核心分类](sub-core-taxonomy.md#the-deepsea-umbrella-and-the-compiler-base-namespace)中。

---

## 按代号区分

Ghostlite 和 6acc60406 共享 VXC HAL 产品链（216 B impl、`TpuVxcDriver`、V2 描述符）以及一个 bundle 编码器（`ProgramProtoUtil::BundleCount` 在 `0x1e830e80` 为 v4 和 v5 共同选择的共享 `CreateEncoderGlGf` 路径），但在 codec/ISA 层显著分化。最清晰的分化是符号可见性和 TensorCore bundle 编码。

> **注意——** 共享的 GlGf 编码器解释了为什么尽管存在具名/匿名 codec 拆分，两个 `gxc` 子核心 ISA 命名空间的 token 权重仍然接近（`gxc::glc::isa` 294K，`gxc::gfc::isa` 270K）：6acc60406 继承了 Ghostlite 的编码器机制，而不是携带完全独立的一套。版本分派侧也显示出同样的配对——`BundleCount` 的 switch 把六代收敛到四个编码器家族（`JfDf`、`Pf`、`Vf`、`GlGf`），其中 v4+v5 共享 `GlGf`，正如 v0+v1 共享 `JfDf`（见[代号矩阵](tpu-version-codename-matrix.md#codec-selection-confirms-the-ordering)）。

| 轴 | Ghostlite (v4 / glc) | 6acc60406 (v5 / gfc) | 来源 |
|---|---|---|---|
| TpuVersion enum | kGhostlite = 4 | k6acc60406 = 5 | `TpuVersionToString` 0x20b3a480 |
| ToString | "ghostlite" (0x86864e0) | "6acc60406" (0x863f0cf) | rodata |
| External / Cloud name | "TPU v6 lite" / `v6e` | "TPU7x" / `tpu7x` | 命名路径 |
| Init module | glc 0x213eb9e0 | gfc 0x213e9f60 | symtab |
| Sub-core | `gxc::glc` (load-core) | `gxc::gfc` (fetch-core) | symtab |
| Codec class | `TpuCodecGhostlite`（具名，`_ZTV` 0x21d35c00） | 匿名（无 codec `_ZTV`/`_ZTI`） | codec 走查 |
| Codec creator | `CreateTpuCodecGhostlite` 0x1e83bce0（具名） | `sub_1E838380`（inline, anon） | disasm |
| Named workers | `ghostlite::isa::EncoderGl{TC,Scs,Tac,Tec}` | gfc `EncoderBase` templates（无 `EncoderGf*`） | symtab |
| LLVM subtarget | `TPUGlcSubtarget` | `TPUGfcSubtarget` | symtab |
| Cost-model table | `GlcCycleTable` (`_ZTV` 0x21c20148) | `GfcCycleTable` (`_ZTV` 0x21c201c8) | symtab |
| Codec metadata | `GhostliteCodecMetadata`（具名，`_ZTV` 0x21d647a8） | 匿名 registry 条目 | disasm |
| Codec platform tag (cmp) | `$0x5`（Ghostlite 的 proto value） | `$0x6`（6acc60406 的 proto value） | Encode body |
| Entry-point opcodes | 0x11/0x12/0x13/0x14 (TC/Scs/Tac/Tec) | 0x15/0x16/0x17（+4 shift） | Encode body |
| TensorCore bundle | 64 B；4 VALU；7-bit opcode @302；4-bit pred @309 | 64 B；4 VALU；8-bit opcode @293；2-bit dual pred @301 | VALU0 encoder bytes |
| TC CodecBase object | 240 B（1 个 `Predication` param） | 248 B（4 个 predication params） | EncodeBundle `new()` |
| PCI chip DID | 0x00d1（具名 `kGhostliteChip*`） | 0x00f2（匿名 gfc） | DeviceIdentifiers |
| Device-type byte | 0xd (`IsGlc`) | 0xc (`IsGfc`) | `DeviceTypeFromDeviceIdentifiers` |
| Flag prefix | `xla_gf_` (44), `xla_sc_` | `xla_gf_`, `xla_sc_` | flag scan |

> **陷阱——** v5（6acc60406 / gfc）是**唯一完全剥离符号的代号**。它的 codec 类、vtable、typeinfo 和 creator 都没有 demangled 名称；v0..v4 全部保留 `_ZTV`/`_ZTI`/`_ZTS` 符号（只有 RTTI name-string 的*内容*对全部六个 codec 都混淆成了 `s_NNNNN` 标签）。通过符号交叉检查的重新实现者会按名称找到 Ghostlite，但只能按结构恢复 v5 codec（8 字节对象、6-slot vtable、`gxc::gfc::isa` 分派）。v4→v5 的 codec 差异——opcode 从 7 位扩展到 8 位、每槽 predicate 从 4 位缩小到 2 位并放入专用 dual-predicate slot、entry-point opcode +4 偏移、TC CodecBase 从 240 B 增长到 248 B——就是需要匹配的结构指纹。

---

## 交叉引用

- [VXC 家族](vxc-family.md)——GXC 注册进入的家族；共享工厂、impl、driver 和 `InitializeDrivers` switch
- [JXC 家族](jxc-family.md)——没有 fetch/load 拆分的 fused-dataflow 祖先
- [PXC 家族](pxc-family.md)——引入了 GXC 子核心继承的 fetch/load 拆分
- [子核心分类](sub-core-taxonomy.md)——作为最新 fetch/load 子核心的 `gfc`/`glc`；trace-entry 类
- [HAL 家族](hal-families.md)——共享的 `TpuHalFactory` 基链
- [代号矩阵](tpu-version-codename-matrix.md)——v4/v5 路由到 VXC 家族；Ghostlite/6acc60406 enum 条目
- [HAL 工厂覆盖矩阵](hal-factory-override-matrix.md)——v4/v5 共享的 VXC impl 覆盖表
- [按代号划分的硬件常量](per-codename-hw-constants.md)——bundle/ISA 分化背后的 v6e/v7x chip-parts 常量（256×256 MXU、SparseCore sequencer 差异）
- [PCI 设备 ID](pci-device-ids.md)——区分表中 chip-DID（`0x00d1`/`0x00f2`）和 device-type（`0xd`/`0xc`）行的来源
- [营销 / Cloud 命名](marketing-cloud-naming.md)——`v6e`/`tpu7x` Cloud 名称，以及为什么公开营销名称只是外部信息而不是二进制事实

GXC 家族（Ghostlite, 6acc60406） ​

摘要 ​

工厂绑定与注册 ​

目的 ​

入口点 ​

函数映射 ​

工厂 vtable ​

子核心子命名空间清单 ​

工厂下方的构造链 ​