OpenQASM 3: A broader and deeper quantum assembly language

• OpenQASM 2 [1] became a de facto interchange standard, and OpenQASM 3 updates the language to support substantial classical control flow beyond the circuit model.Source: §1 · p. 3
• Extended quantum circuits combine ordered quantum operations with real-time classical computation, with data flowing between them as operations use measurements and classical results condition quantum actions.OpenQASM models execution as dataflow: an instruction may run independently when its input data becomes available.Source: §1 · pp. 3–4
• OpenQASM adds time-domain gate scheduling and extensible, platform-agnostic descriptions of gate implementations, while remaining backward compatible except for some uncommon breaking changes.These semantics support circuits used to characterize, validate, and debug quantum systems.Source: §1 · p. 3
• OpenQASM 3 focuses on real-time classical computation within qubit coherence times, rather than near-time computation, which existing programming tools and frameworks already describe adequately.Real-time computation supports feedback, feedforward, and error correction, but may face limited memory or reduced clock speeds.Source: §1 · pp. 3–4
• OpenQASM sits in the middle of the software stack, and its features address hand authors, compiler researchers, experimentalists, and hardware controller engineers.The language may be hand-written or generated by tools, then compiled into lower-level analog-signal instructions.Source: §1 · p. 4
• This manuscript explains OpenQASM 3’s new features and design intent rather than serving as its formal specification, which is maintained as a live document.Source: §1 · p. 4

2.1 Versatility in describing logical circuits

• Nondeterministic repeat-until-success [30] and magic-state distillation [31] can use classical control flow, while measurement and feedforward enable constant-depth Clifford operations and quantum Fourier transforms.The extensions also support teleportation and feedforward in the measurement model.Source: §2.1 · p. 5
• OpenQASM 3 targets real-time classical computations tightly coupled to quantum hardware, leaving near-time preprocessing, postprocessing, and variational-algorithm loops to existing frameworks while permitting external real-time functions.Examples of near-time work include choosing a co-prime in Shor’s algorithm [33] and computing Pauli expectation values; real-time functions are defined outside OpenQASM itself.Source: §2.1 · p. 5

2.2 Versatility in the level of description for circuits

• OpenQASM 3 serves as a multi-level intermediate representation, from logical discrete-time gates and real-time computation to physical implementations using timed, continuous signals.Timing and pulse features support calibration, characterization, error mitigation, dynamical decoupling [34], and decoherence and crosstalk characterization [35]; compiler semantics enable rewriting at different abstraction levels while preserving portable intent.Source: §2.2 · pp. 5–6

2.3 Continuity with OpenQASM 2

• Although OpenQASM 2 compatibility is not prioritized above all else, OpenQASM 3 aims to minimize incompatibilities and preserve the meaning of OpenQASM 2 circuits.The stated goal is to reduce disruption to existing software projects and ease adoption for developers familiar with OpenQASM 2.Source: §2.3 · p. 6

2.4 Execution model

• Quantum programs emit circuit payloads and external real-time functions for compilation into physical OpenQASM, which is mapped and scheduled on specific qubits before target code generation.Programs may enter the toolchain at varying abstraction levels, and the model assumes a global QPU controller for control flow and external computations; local controllers may enable concurrent independent segments.Source: §2.4 · pp. 6, 8, Figure 1 · p. 7

Circuit header; Circuit execution

• OpenQASM 3 circuits can use the same versioned header and include statements as OpenQASM 2, and may execute as top-level instruction sequences without an explicit entry point.Execution begins with the first instruction after the header.Source: Circuit header · p. 8, Circuit execution · p. 8

Quantum and classical registers; Names of gates, variables, and constants

• OpenQASM 3 supports qreg and creg syntax alongside preferred qubit and bit declarations, and relaxes identifier rules while changing the keyword set.Identifiers may begin with capitals, underscores, or a range of Unicode characters; names that become version 3 keywords must be changed.Source: Quantum and classical registers · p. 9, Names of gates, variables, and constants · p. 9

Basic operations; Barrier instructions

• OpenQASM 3 retains U, reset, measure, and barrier operations, but CX is no longer a basic instruction and can be defined using the ctrl @ modifier.The U specification differs by a global phase, which has no effect on circuit results; reset and measure retain their meanings, and barriers have the same meaning.Source: Basic operations · pp. 9–10

Gate declarations

• OpenQASM 3 retains OpenQASM 2 gate-declaration syntax and unitary-only gate bodies, while allowing greater versatility in describing those operations and other subroutines.Gate bodies may sequence basic unitary operations or operations defined by earlier gate declarations.Source: Gate declarations · p. 10

Implicit iteration

• OpenQASM 3 preserves implicit iteration across registers for gate subroutines, but this feature does not apply to its other kinds of subroutine.Omitting an index repeats an operation across the corresponding register; when both two-qubit arguments omit indices, iteration uses matching indices.Source: Implicit iteration · p. 10

Control flow

• OpenQASM 3 preserves bit-register comparisons and conditional gates, while adding more general if syntax and other forms of control flow.OpenQASM 2’s if statements compare a classical register, interpreted as an integer, with an integer and conditionally execute a single gate.Source: Control flow · pp. 10–11

Opaque definitions

• OpenQASM 3 compilers ignore opaque declarations, because the language provides lower-level means to define operations beyond unitary gates.OpenQASM 2 used opaque declarations for gates whose physical implementation could not readily be expressed in terms of unitary gates.Source: Opaque definitions · p. 11

Circuit output

• OpenQASM 3 circuits default to outputting all classical stored variables unless input or output variables are explicitly declared.This default includes variables declared as creg and variables of other types.Source: Circuit output · p. 11

4 Concepts of the language: the logical level

• This section presents key features of the logical level, while lower-level features are covered in Section 5 and the live specification.The specification is identified as the source for a finer-grained description.Source: §4 · p. 11

4.1 Continuous gates and hierarchical library

• OpenQASM 3 combines continuous single-qubit gates, modifiers, and hierarchical composition for universal operations, without requiring a fixed compilation target or a built-in CX keyword.Practical gates can have polynomial-size circuit representations, though a general n-qubit gate may require exponentially many component gates. CX remains in the standard library for backward compatibility.Source: §4.1 · pp. 12–13
• The OpenQASM 3 U definition differs from OpenQASM 2 by a global phase, which is unobservable for OpenQASM 2 circuits but can become relative when a gate is controlled.The built-in gphase instruction adds an arbitrary global phase to its scope; U is the only uppercase keyword in OpenQASM 3.Source: §4.1 · pp. 12–13
• Hierarchical gate declarations reuse built-in or previously defined gates, but do not prescribe hardware instructions; the user or compiler determines implementation for the target.This separates a gate’s defined unitary transformation from how a particular device executes it.Source: §4.1 · p. 12

4.1.1 Standard gate library

• Circuits that include stdgates.inc can use its standard gates, including composed swap and Toffoli gates and a backward-compatible CX definition.The library defines gates through gate composition and modifiers.Source: §4.1.1 · pp. 14–15

The control modifier

• The Fredkin gate has equivalent direct and controlled-swap definitions, and a compiler may infer their equivalence or rewrite one form into the other.The direct definition uses fewer controlled operations; compiling the defined Toffoli may still require synthesis into more primitive gates or pulses.Source: The control modifier · pp. 15–16
• ctrl and negctrl add positive- or negative-polarity controls to gates, with optional control counts specified by compile-time constants.A single ctrl @ g is defined by the matrix I ⊕ g; compilers may synthesize controlled gates using ancillary qubits to reduce circuit size or depth.Source: The control modifier · pp. 15–16

The inversion modifier

• inv @ g denotes g† and can be derived recursively by reversing a gate definition and inverting each operation.Inversion commutes past control, while U(a, b, c) becomes U(-a, -c, -b) and gphase(a) becomes gphase(-a).Source: The inversion modifier · p. 17

The powering modifier

• pow(r) @ g denotes the real rth power of g, defined using its principal logarithm; integer powers can use repeated gates, but compilation generally requires synthesis or optimization.For positive integer r, repeat g r times; for negative r, repeat its inverse |r| times, a potentially less efficient implementation.Source: The powering modifier · pp. 17–18

4.3 Non-unitary operations

• Measurement projects a qubit onto a Z-basis eigenstate, stores the outcome in a bit, and leaves the qubit available for further computation.It also measures qubit arrays and stores their outcomes in same-length bit arrays.Source: §4.3 · p. 18
• For OpenQASM 2 compatibility, measurement also supports measure q -> r for matching qubits and bit variables or registers.Source: §4.3 · p. 18
• Reset returns a qubit to |0⟩; ideally, it measures in the standard basis, applies Pauli X for outcome 1, and discards the outcome.Mathematically, reset discards the qubit via a partial trace and replaces it with a new qubit in state |0⟩; it also works on arrays.Source: §4.3 · p. 18

4.4 Real-time classical computing

• OpenQASM 3 adds classical data types, arithmetic, logical instructions, and control flow, making classical computation Turing-complete in principle alongside quantum operations.These extensions address dynamic circuits that combine classical control flow and concurrent classical computation.Source: §4.4 · p. 19

Classical types:

• The type system balances programmer intent in logical circuits with controller constraints in physical circuits, offering common types, configurable widths, and bit-level access.The fixed-point angle[n] type represents phases in a bounded binary format that can use numerical overflow to constrain phase values without floating-point modular arithmetic.Source: Classical types · pp. 19–20

Classical control flow:

• OpenQASM 3 adds while and for loops and permits multi-instruction if bodies and else blocks, preserving iterative structure that OpenQASM 2 circuits had to unroll.The unrolled Fourier-sampling example illustrates the motivation for these constructs.Source: Classical control flow · pp. 20–21

Subroutines:

• Classical subroutines can be written within the language, and quantum procedures can use measurement-dependent while loops, as in repeat-until-success circuits.In the example, the computation terminates only when the desired measurement outcome is observed.Source: Subroutines · p. 22

External functions:

• OpenQASM 3 uses extern declarations to connect circuits to opaque classical computations, allowing existing libraries and compiler toolchains to be used without porting code.An extern call schedules computation without itself creating a synchronization boundary; a compiler may insert target-specific synchronization where outputs are used.Source: External functions · p. 23

4.5 Input and output parameters

• The input and output keywords modify variable declarations to mark runtime inputs and select the variables returned by a quantum procedure.A variable cannot be marked as both input and output.Source: §4.5 · p. 24
• An input declaration marks values supplied at invocation; omitting it preserves compatibility by assuming no input parameters.With inputs declared, the compiled executable leaves those parameters unspecified, and a run supplies both the executable and parameter values.Source: §4.5 · p. 24
• An output declaration selects which variables are returned; if omitted, OpenQASM 3 assumes all declared variables are outputs.OpenQASM 2 returned all classical variables and did not let programmers select an output subset.Source: §4.5 · p. 24
• For variational quantum algorithms such as VQE [21], one parameterized program can be run repeatedly with different free parameters to minimize an expectation value.This allows a single compiled program to serve many runs, amortizing compilation across them.Source: §4.5 · p. 24
• Input/output parameter circuits move compilation outside repeated runs, compiling once and reusing the executable with each new θ value.The VQE pseudocode illustrates this: each iteration runs the existing binary with a different θ instead of recompiling the program.Source: §4.5 · p. 25

5 Concepts of the language: the physical level

• At the physical level, OpenQASM 3 lets hardware-aware programmers influence pulse implementations to trade calibration accuracy for shorter duration or use delays for dynamical decoupling.Such choices can suit variational ansätze where minimizing decoherence matters, or spin-echo sequences that counter slowly drifting hardware errors.Source: §5 · pp. 25–26

5.1 Timing and optimization

• Timing semantics support circuits for decoherence and crosstalk characterization, dynamical decoupling, dynamically corrected gates, and gate parallelism or scheduling.Source: §5.1 · p. 26

Delay statements and duration types:

• A delay statement specifies relative operation timing with a duration value measured in seconds and typically expressed with SI prefixes.The duration type supports timing instructions such as delay[t].Source: Delay statements and duration types · p. 26
• Instructions with bracketed durations must take exactly the specified time, and may be non-executable if no compatible defcal exists.The passage gives x[30ns] q[1] as an example of a gate with an assigned duration.Source: Delay statements and duration types · p. 26

Boxes and barrier statements:

• A box constrains compiler optimization: it permits optimization within its code but forbids moving operations into or out of the box.The compiler may use a description of the box’s operation to reorder gates around it, allowing optimization without disturbing a boxed dynamical-decoupling sequence. A box may also have an assigned duration to constrain scheduling.Source: Boxes and barrier statements · pp. 26–27
• Barriers impose ordering constraints across their source line, while delay statements also prevent reordering and indicate a fully scheduled sequence.A barrier is like delay[0], but scheduling may add finite delays beside it; neither delay nor barrier constraints escape a containing box.Source: Boxes and barrier statements · pp. 27–28

Stretch types:

• A stretch represents a relative duration that the compiler minimizes subject to timing constraints, enabling gate alignment without depending on calibrated gate durations and improving circuit portability.Stretches can express even spacing, left alignment, or matching a gate’s duration to a subcircuit; their values resolve to concrete durations at compile time.Source: Stretch types · p. 28
• Resolving stretches requires multiobjective linear programming because timings across connected qubits interact, and stretches are limited to linear combinations unavailable for nonlinear expressions or control flow.Duration values do not require linear-program solving and can be used more freely. A duration-assigned box can constrain its internal stretches; if natural instruction durations exceed that box duration, compilation errors.Source: Stretch types · pp. 28–31

5.2 Calibrating quantum operations

• Calibration support addresses platform-dependent control signals and enables hardware/software co-design as quantum hardware and control-signal techniques evolve.Control hardware emits calibrated signals to implement quantum operations; updates to control-signal designs can improve existing hardware.Source: §5.2 · p. 31
• defcal declarations specify microcoded implementations of gates, measurements, or resets for target hardware, and their support is optional.Unlike gate declarations, defcal implementations target physical qubits and may specify parameter precision matching native hardware; compilers link circuit instructions to them. A defcal without a corresponding gate declaration is treated as an opaque operation.Source: §5.2 · pp. 32–33

Calibration resolution

• Calibration dispatch specializes implementations by physical qubit and gate parameters, while scheduling requires compile-time-computable durations and resource information.When a duration depends on input parameters, those parameters and the calibration must be resolvable at compile time; calibrations must also be invocation-time independent for substitution anywhere the circuit instruction occurs.Source: Calibration resolution · pp. 33–34

Calibration grammars

• Vendors can supply pluggable calibration grammars, which OpenQASM uses as a standardized lowering pipeline from hardware-agnostic circuits to hardware-aware implementations.The grammar may range from mappings to custom hardware calibrations to a full pulse-programming language; compiler support for calibration is optional.Source: Calibration grammars · p. 34

OpenPulse grammar

• OpenPulse provides a hardware-independent pulse-level representation using device-specific ports, carrier-tracking frames, and waveforms played on frames.Frames track frequency and phase, enabling virtual Z-gates through phase shifts; measurement and reset calibrations can use vendor-provided external readout routines.Source: OpenPulse grammar · pp. 34–36
• OpenPulse uses relative timing and barriers to synchronize frames, while defcal calls and external frames expose indirect qubit use to the scheduler.Every frame used in a cal or defcal begins and ends with an implicit barrier; informing the scheduler of indirectly coupled qubits helps it avoid scheduling them simultaneously.Source: OpenPulse grammar · pp. 36–37

5.3 Solving the stretch problem

• The compiler treats stretch durations as variables in a linear inequality system and resolves them in a late-stage pass into explicit delays and a complete schedule.The schedule is defined for operations within each basic block when the stretch problem is bounded and feasible.Source: §5.3 · pp. 37–38
• The bounded stretch problem is a lexicographic multi-objective linear program with a unique optimum when feasible; infeasible targets produce compiler errors.The objectives can be optimized in sequence, and multiobjective optimization is implemented in software such as CPLEX.Source: §5.3 · p. 38
• For each basic block, the solver equates the duration of operations on every qubit and lexicographically minimizes stretch variables, including the block’s total duration.Each qubit’s duration depends on operation and delay durations and on scheduling constraints for multi-qubit instructions.Source: §5.3 · p. 38
• For dynamical decoupling, the solver fixes T, s, t, and r while setting xlen and ylen to their target minimum durations A and B.The stretch design places pulse centers equidistantly and accounts for finite gate durations.Source: §5.3 · pp. 38–39
• Reversing stretch-variable declaration order changes the optimization order and can switch the resulting schedule from left-aligned to right-aligned.In the example, minimizing a, b, c, d yields a left-aligned schedule; declaring d, c, b, a instead yields a right-aligned one.Source: §5.3 · pp. 39–40

5.4 Multi-level representation

• OpenQASM serves as a multi-level intermediate representation, ranging from target-agnostic constructs to concrete implementations, while allowing constraints where needed and compiler choices elsewhere.Examples include assigning a virtual qubit to a physical qubit or left-aligning parallel gates of different durations.Source: §5.4 · p. 40
• An explicit delay supplies circuit timing and prevents otherwise permitted gate commutation, whereas an implicit delay leaves the RZ gate free to commute.The figure illustrates this distinction for gates on qubit 0.Source: §5.4 · p. 40, Figure 7 · p. 41
• Stretch constraints can remain with a high-level circuit and be inserted automatically when a gate containing them is expanded.The paper illustrates this with alignment constraints for simultaneous randomized benchmarking across varying Clifford decompositions.Source: §5.4 · p. 40, Figure 8 · p. 41

6 Compilation phases by example

• Iterative phase estimation uses one control qubit and repeated measurements, with each result feeding forward in real time to set later rotation angles during the qubits’ coherence interval.Each measurement adds one bit to the phase estimate.Source: §6 · p. 42

6.1 Target-independent compilation phase

• Target-independent compilation propagates and folds constants, evaluates and synthesizes gate modifiers, unrolls statically bounded loops, and removes identity rotations to simplify the circuit.Unrolling can expose further optimizations, such as removing a reset redundant with the initial reset.Source: §6.1 · pp. 43–45

6.2 Target-dependent compilation phase

• Target-dependent compilation translates gates to a target basis, simplifies gates, and maps virtual qubits using device connectivity; the example assumes phase, h, and cx gates and needs no routing.The target class is refined across transformations; the example’s CNOT connects physical qubits 0 and 1 in either direction.Source: §6.2 · pp. 45–47
• Scheduling uses stretch delays for an “as late as possible” policy without concrete gate durations, then calibration linking resolves stretches and rounds angles to defcal precision.Gate, reset, and measurement pulse sequences supply the durations; the compiled circuit then goes to target code generation and execution, with further target-dependent phases beyond OpenQASM 3’s scope.Source: §6.2 · pp. 48, 49, 52

7.1 Comparison to other quantum programming languages

• OpenQASM and Quil are standalone, portable intermediate representations, unlike high-level languages embedded in C/C++, Haskell, Python, or LLVM [13].Source: §7.1 · p. 52
• OpenQASM 3 adds types such as angle and semantic definitions of purely classical extern functions for real-time computation.Source: §7.1 · p. 53
• Gate modifiers decouple modified-gate semantics from implementation, and with the U gate and gphase built-ins generate the standard gate library.Source: §7.1 · p. 53
• OpenQASM 3 streamlines circuit timing through pulse-independent constraints using stretch, while box scopes code blocks and guides compiler optimization; barriers [1] and pragmas [13] offered more limited precedents.Source: §7.1 · p. 53

7.2 Features considered but not adopted

• OpenQASM 3 omits mid-circuit qubit allocation and de-allocation and classical-code-to-reversible-circuit compilation, staying closer to executable circuits to manage compiler complexity.Source: §7.2 · p. 53
• OpenQASM 3 uses global-scope execution and for and while loops rather than explicit entry points or assembly-style jumps, supporting compatibility, human programmability, and compiler timing analysis.Source: §7.2 · p. 53

7.3 Considering further language features for OpenQASM

• Potential future features include unitary circuit families, generic OpenQASM subroutines, classical arrays, and reconsideration of fixed-point real numbers through community working groups.Source: §7.3 · pp. 53–54

8 Conclusion

• OpenQASM 3 adds features for physical implementation and quantum-classical interaction, spanning high-level gate modifiers to low-level microcoded gate implementations.The paper illustrates these features and representations across abstraction levels and use cases.Source: §8 · p. 54
• The live language specification is expected to evolve with hardware and real-world use, with proposals including changes to implicit type conversions and generic functions for code reuse.The authors plan a formal process for reviewing proposed changes.Source: §8 · p. 54