12 Lowering 规则

目的

本章定义从 UQCI 抽象到兼容层与后端导向形式的 lowering 规则。

基本原则

Lowering 必须遵循两条原则：

1. 逻辑语义优先于物理细节
2. 设备特有信息优先保留在 DeviceSpec、CalSet 与 backend 模块中，而不是硬编码进主 QASM 文件

这两条原则与参考草案以及仓库 OpenQASM 兼容桥文档保持一致。Lowering 不是转移语义归属权的理由。

三类表示形式

为避免概念混淆，本仓库应区分三类表示形式：

• canonical semantics：由 UQCI 模型表达的语义真源
• export semantics：按 profile 成形的 OpenQASM 兼容输出
• 面向后端的形式：调度后计划、目标原生编译产物或其他内部执行形式

Lowering 可以在这些形式之间进行转换，但必须尽量保持执行意图不丢失。

代表性映射

• GateOp -> 标准门语法或自定义 gate 形式
• timing 意图 -> duration、delay、box、stretch、barrier 等构造
• 单 qubit pulse 意图 -> 更高 profile 中的 defcal 或 OpenPulse 对齐形式
• entangler pulse 意图 -> 带 sidecar 引用的校准感知形式
• classified measurement -> measure -> bit 或等价表达
• raw measurement 意图 -> profile-aware capture hint 与 backend-specific 处理
• routing 或 shot policy -> namespaced pragmas

参考草案还点出了虚拟相位更新、资源锁、校准绑定与其他执行提示。这些内容应根据 profile 与目标平台，分别落入 namespaced 注解、pragma、sidecar 引用或 backend-native 内部形式。

意图保持规则

Lowering 的核心要求，是在目标表示能力允许的范围内尽量保持 canonical 程序的执行意图。具体包括：

• 在引入目标细节前先保留逻辑门语义
• 在 timing-aware profile 中保留时序意图
• 通过 sidecar 或 profile 兼容构造保留校准引用
• 保留执行提示，但不把提示误升级为 canonical 语义

如果目标表示形式无法承载 canonical 程序的全部细节，lowering 边界应显式暴露这一限制，而不是静默降级。

推荐流程

推荐 lowering 流程如下：

1. 先根据 DeviceSpec 能力边界验证 UQCI program
2. 选择导出 profile：OQ-0、OQ-1、OQ-2 或 OQ-X
3. 将门级语义下降到可移植 OpenQASM
4. 按需将 timing 语义下降到 delay-like constructs
5. 在 profile 允许时附加 calibration-aware 内容
6. 发射 UQCI namespaced annotations 与 pragmas
7. 将导出后的程序与 manifest、devicespec、calset、可选 pulseir 一并打包

兼容导出与后端导向 Lowering 的区分

compatibility export 只是 lowering 的一种路径。backend 还可以直接从 canonical UQCI 语义降低为：

• 调度后的内部计划
• 带资源注释的执行计划
• 目标原生 pulse 或控制序列
• 用于测试的 mock 执行计划

即便完全不产生 OpenQASM，这些面向后端的形式也仍然位于 canonical 语义与 sidecar 的下游。

Profile 敏感性

Lowering 天然对 profile 敏感：

• OQ-0 优先最大可移植性
• OQ-1 尽量保留时序意图
• OQ-2 允许 calibration-aware 导出
• OQ-X 提供最丰富的 QOS 导向兼容表面

因此，所选 profile 应被理解为导出策略，而不是对 canonical 程序的重新定义。

实用性规则

Lowering 应保持 practical 与 modular。仓库 v0.1 不要求提供完整通用 parser，也不要求实现所有平台上的通用 pulse compiler。

实现应优先采用显式、可审计的 lowering 步骤，而不是依赖会模糊 canonical 语义、compatibility export 与 backend-native 落地边界的黑箱捷径。