---
title: 'DistQASM: Distributed Quantum Assembly Language'
url: https://www.emergentmind.com/topics/distqasm
type: topic
---

# DistQASM: Distributed Quantum Assembly Language

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 [2509.02827], [2404.17077].

## 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 [2509.02827], [2404.17077].

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 [2509.02827].

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 [2305.02969], [2501.11816].

## 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:

```c
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 [2509.02827].

Remote execution context is expressed with block markers:

```c
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 [2509.02827].

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 [2509.02827].

## 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 [2509.02827].

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 [2509.02827].

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 [2509.02827].

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:

```c
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 [2509.02827].

## 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 [2509.02827].

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 [2509.02827].

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 [2509.02827].

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 [2509.02827].

## 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 [2404.17077].

The same work formulates distributed compilation as a Markov Decision Process with state
\[
s_t = \left(Q^{EPR}_t, f_t, c_t, G_t\right),
\]
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 [2404.17077].

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 [2305.02969].

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 [2501.11816].

## 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 \(1\%\), 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 \(\sim 70\%\) 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 [2509.02827].

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 [2509.02827].

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 [2509.02827].

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 [1001.1722], [2509.02827].

Source: https://www.emergentmind.com/topics/distqasm