DistQASM: Distributed Quantum Assembly Language
- DistQASM is a distributed quantum programming language that explicitly specifies node-aware qubit declarations and remote execution blocks.
- It extends OpenQASM with remote block markers and dedicated distributed protocol instructions like teleport, cat_ent, and cat_disent.
- The language bridges high-level distributed quantum algorithms to QNPU ISA operations, enabling concurrent remote operations and improved execution scalability.
Searching arXiv for DistQASM and closely related distributed quantum programming/compiler papers. First, I’ll look up the exact DistQASM paper and a few neighboring works on distributed quantum compilation/languages to ground the article in current arXiv records. DistQASM is a language introduced to facilitate programming quantum supercomputers by extending OpenQASM with distributed quantum operations, and it is also envisioned as a distributed generalization of QASM for specifying and running quantum programs across multiple Quantum Processing Units (QPUs). Its central purpose is to make node placement, remote execution context, and distributed quantum communication explicit at the language level, while leaving the decomposition of those operations into entanglement management, classical synchronization, and hardware-specific actions to the compiler and runtime (Li et al., 2 Sep 2025, Promponas et al., 2024).
1. Position within distributed quantum computing
Distributed Quantum Computing (DQC) is presented as a scalable path for executing quantum programs that require larger qubit systems than a single processor can provide. In that model, multiple QPUs are interconnected through quantum links, EPR pairs are generated and shared between distant QPUs, and remote execution relies on quantum teleportation and related protocols. DistQASM sits at the programming interface for this setting: it provides a representation in which distributed operations are explicit enough for compilation and execution across nodes, but remains close to established circuit-oriented practice by extending OpenQASM rather than replacing it (Li et al., 2 Sep 2025, Promponas et al., 2024).
In the QNPU architecture, each node contains a QPU for local quantum computation and a Quantum Network Processing Unit (QNPU) specialized for quantum communication between nodes. The QPU and QNPU are physically decoupled, with their own quantum zones and classical controllers, but allow state movement between them using zone transition instructions. DistQASM is designed as the programming layer that bridges high-level distributed quantum algorithms and this hardware-level distributed architecture (Li et al., 2 Sep 2025).
A recurring implication across the distributed compilation literature is that a practical language for DQC cannot be limited to gate lists alone. It must also expose qubit placement across modules, remote-operation selection, and resource-sensitive execution. This is why DistQASM is naturally discussed alongside partitioning, remote scheduling, and EPR management frameworks rather than solely as a syntactic extension of OpenQASM (Ferrari et al., 2023, Cha et al., 21 Jan 2025).
2. Core language extensions
DistQASM extends OpenQASM in three principal ways: node-specific qubit declarations, remote block markers, and explicit distributed quantum protocol instructions. The node-specific declaration syntax attaches a physical node identifier to a register, making qubit location part of the program text rather than an implicit compiler-side decision. The canonical examples are:
1 2 |
qreg q[2] @nodeA; qreg r[2] @nodeB; |
This introduces what the source describes as spatial awareness into the code, letting the programmer indicate which physical node hosts each qubit (Li et al., 2 Sep 2025).
Remote execution context is expressed with block markers:
1 2 3 |
pragma remote_begin nodeB ... pragma remote_end |
These directives specify that the enclosed code operates on a remote node and clarify which parts of a program run locally or remotely. The mechanism is intended to support context switches for remote execution while preserving a circuit-like programming style (Li et al., 2 Sep 2025).
The main extensions relative to OpenQASM can be summarized as follows:
| DistQASM extension | Description | OpenQASM baseline |
|---|---|---|
Node-aware qreg |
qreg q[n] @nodeX; |
qreg q[n]; |
| Remote block markers | pragma remote_begin nodeX ... pragma remote_end |
Not present |
| Remote operations | teleport, cat_ent, cat_disent |
Not present |
A common misunderstanding is to treat these constructs as mere annotations. In the language description, they are not passive metadata: they are intended to drive protocol selection, instruction translation, and cross-node coordination in the execution stack (Li et al., 2 Sep 2025).
3. Distributed operation model and protocol semantics
DistQASM introduces first-class instructions for distributed quantum communication protocols. The key operations are teleport <src_qubit>, <dst_qubit>, cat_ent <src_qubit>, <dst_qubit>, and cat_disent <dst_qubit>, <src_qubit>. The paper associates these instructions with two protocol families: TP-Comm for teleportation and Cat-Comm for distributed entanglement and disentanglement (Li et al., 2 Sep 2025).
The semantics of these operations are described as atomic remote operations. That is, the programmer writes a single distributed instruction, while the compiler is responsible for decomposing it into the low-level operations executed across cooperating nodes. This decomposition must ensure that classical and quantum synchronization, EPR pair consumption, and final state movement are handled correctly. DistQASM therefore exposes the existence of distribution while abstracting away the full protocol transcript (Li et al., 2 Sep 2025).
The distinction between TP-Comm and Cat-Comm is operationally important. teleport moves a quantum state from a qubit on the local node to a qubit on the remote node using an EPR pair. cat_ent establishes remote entanglement between two qubits, one on each node, without full teleportation, and cat_disent performs disentanglement after the remote operation. The language deliberately exposes this choice so that programs can select the desired underlying distributed quantum protocol depending on capabilities and performance considerations (Li et al., 2 Sep 2025).
The distributed GHZ examples illustrate the intended programming model. Under TP-Comm, an entangled qubit is teleported to the remote node and subsequent work is placed inside a remote block. Under Cat-Comm, remote entanglement is established first, the remote gate is executed inside the remote block, and disentanglement is then made explicit:
1 2 3 4 5 6 7 8 9 |
qreg q[2] @nodeA; qreg r[2] @nodeB; h q[0]; cnot q[0], q[1]; cat_ent q[1], r[0]; pragma remote_begin nodeB cnot r[0], r[1]; pragma remote_end cat_disent r[0], q[1]; |
This style makes distributed quantum logic readable in circuit form while preserving protocol awareness (Li et al., 2 Sep 2025).
4. Translation to QNPU ISA and micro-operations
DistQASM is tightly coupled to a lower-level execution model in which distributed instructions are translated into QNPU instruction set architecture (ISA) operations. For teleportation, the translation example begins on the source node with a zone transition that moves the qubit state from the computation zone to the communication zone, followed by a SEND_TP_QUBIT instruction issued by the QPU to the QNPU. On the destination node, the QNPU executes GET_TP_QUBIT, identifies which EPR pair or qubit to receive, signals the QPU when done, and the received state is moved into the computation zone by another zone transition (Li et al., 2 Sep 2025).
The principal DistQASM-to-QNPU ISA instructions listed for the two protocol families are:
SEND_TP_QUBIT <qubit>, <dst_node>GET_TP_QUBIT <qubit>SEND_CAT_ENT_QUBIT <qubit>, <dst_node>GET_CAT_ENT_QUBIT <qubit>SEND_CAT_DISENT_QUBIT <qubit>, <src_node>GET_CAT_DISENT_QUBIT <qubit>
The translation also uses TRANSFER_SUCCESS_NOTIFY and zone transition instructions (Li et al., 2 Sep 2025).
Below the ISA, each high-level QNPU instruction is decomposed into micro-operations grouped into three classes: EPR resource management, classical communication, and quantum operations. For teleportation, the described sequence reserves an EPR pair, synchronizes the pair ID with the target node, performs local gates and measurements, communicates measurement results, applies state corrections at the destination, and notifies completion for resource recycling and zone transition. DistQASM is therefore not just a source syntax for remote gates; it is the front end of a multi-layer execution pipeline with explicit responsibilities for resource handling and protocol orchestration (Li et al., 2 Sep 2025).
This layering also clarifies the role of the QNPU. The QPU remains responsible for local quantum operations, while the QNPU manages quantum communication between nodes. DistQASM instructions are the point at which these two processing units become coordinated through a shared distributed program representation (Li et al., 2 Sep 2025).
5. Compilation, scheduling, and optimization context
The broader compilation literature indicates that DistQASM is best understood as part of a distributed compilation stack rather than as a purely declarative assembly syntax. A DistQASM-inspired execution framework has been described as requiring lowering a program to a circuit partitioned across QPUs, insertion of remote operations such as teleportation and SWAPs together with EPR management opcodes, and online scheduling that adapts to dynamic resource states and failures. In that account, the RL-based compiler model directly informs the DistQASM runtime/compilation stack by enabling smart insertion and scheduling of distributed operations that could be encoded as DistQASM instructions (Promponas et al., 2024).
The same work formulates distributed compilation as a Markov Decision Process with state
where the state tracks available EPR pairs, logical-to-physical qubit mapping, cooldown timers, and the remaining circuit as a DAG. The action space includes local CNOT or SWAP, EPR pair generation, remote gate teleportation, qubit teleportation, and a null action that lets time advance. The stated objective is to minimize expected circuit execution time before decoherence, and simulations show that Double Deep Q-Networks are effective in learning policies that minimize the depth of the compiled circuit, leading to lower expected execution time and lower likelihood of failure before decoherence (Promponas et al., 2024).
Earlier modular compilation work is consistent with this picture. It models partitioning by converting a circuit into an undirected weighted graph, solving a multiway graph partitioning problem using METIS, and then scheduling remote operations using TeleGate and TeleData under network and device constraints. That framework explicitly argues that a distributed QASM should distinguish TeleGate and TeleData operations, annotate explicit resource requirements such as EPR pairs and communication qubits, encode parallel scheduling of remote and local operations, and allow embedding of device and network topology information as metadata (Ferrari et al., 2023).
A complementary line of work treats distributed circuit distribution as an exact integer-programming problem once a module allocation is fixed. In that formulation, a module allocation function can be obtained by any front-end method, after which the binary integer program optimally schedules the migrations needed to cover non-local gates and minimize ebit cost. This has been proposed as a post-processing step that could be integrated into a DistQASM workflow, improving on hypergraph partitioning when the allocation is held fixed (Cha et al., 21 Jan 2025).
6. Evaluation, comparisons, and conceptual neighbors
The DistQASM paper ties language design to measurable execution behavior through the QNPU evaluation. On its own, simply decomposing work into QPU and QNPU resulted in modest, below , speedups due to removal of contention between local and communication operations. The major gains arise with superscalar QNPU pipelines supporting concurrent remote operations, yielding up to reductions in execution time for communication-intensive circuits such as QFT, VQE, and QAOA. The reported interpretation is that the decoupled and explicit model supported by DistQASM enables the architecture to exploit concurrency across remote operations (Li et al., 2 Sep 2025).
The evaluation also emphasizes a scaling condition: node scaling behavior shows optimal performance when circuits are distributed so that per-node remote gate counts are balanced, while superscalar QNPU performance saturates as per-node parallelism limits are reached. A plausible implication is that DistQASM’s explicit remote operations and node-aware declarations are not merely descriptive; they create the structural visibility needed for a compiler and target microarchitecture to extract communication parallelism (Li et al., 2 Sep 2025).
In comparative terms, OpenQASM 3 supports classical-quantum control and control flow but lacks distributed or multi-node primitives; DistQASM adds those primitives explicitly. The DistQASM paper also contrasts the language with NetQASM and QMPI: NetQASM is described as focusing on network quantum applications, whereas DistQASM exposes protocol selection and zone-structured, node-aware operations at the language level and is directly tied to a hardware model; QMPI is described as message-passing for quantum programs using function calls, whereas DistQASM enables gate-level, circuit-embedded remote operations (Li et al., 2 Sep 2025).
A more distant conceptual predecessor is the Distributed Measurement Calculus, an assembly language for distributed measurement-based quantum computations with operational and denotational semantics, compositionality, and context-freeness. DistQASM differs in being circuit-based and hardware-oriented rather than measurement-based, but both belong to the class of languages that make distributed resources and communication explicit rather than implicit compilation side effects (D'Hondt et al., 2010, Li et al., 2 Sep 2025).