From N/M to OpenQASM: an export and portability guide

An export is a contract, not a hardware run

OpenQASM is a language for describing quantum programs. Its third version broadens the model to include classical control and other facilities needed to describe more demanding quantum workflows. N/M's exporters translate supported program structures into an OpenQASM representation; they do not make every N/M program compatible with every quantum service.

The useful question is specific: can this source, with these feature settings and this export target, be represented without losing required semantics?

Start with a circuit whose behavior you understand

Run this program in the Playground before exporting it:

module export_bell;
fn main() {
  let q = qreg[2];
  H(q[0]);
  CNOT(q[0], q[1]);
  let c0 = measure(q[0]);
  let c1 = measure(q[1]);
  return q;
}

The ideal distribution is supported on 00 and 11. Choose an OpenQASM export target in the workspace and inspect the generated text. Look for the quantum register, the mapped H and controlled-X gates, the measurement destinations and any accompanying metadata. Keep the original N/M source alongside the export.

If your intended downstream tool is available, parse the result there and inspect its diagnostics. For a round trip through a supported importer, compare circuit behavior and relevant metadata rather than expecting identical formatting or variable names.

Why OpenQASM 2 and 3 are different choices

Basic gate-and-measurement circuits have a straightforward representation in the older format. More elaborate classical control may require the newer format and a narrower exporter contract. N/M features such as training blocks, bounded classical functions or structured metadata can require lowering, a completed parameter context or an accompanying sidecar file.

The sidecar is not a decorative extra. When the exporter indicates that one is required, retain it with the program. A downstream consumer must explicitly understand the N/M-specific contract; parsing the QASM text alone cannot establish that this extra information was preserved.

An unsupported construct should produce a diagnostic, not be silently dropped. Read the actual export result for the chosen program. The N/M documentation and RFC archive explain the supported contracts; the OpenQASM specification explains the standard language. These are related sources with different responsibilities.

A useful portability checklist

• Preserve the original source and all export settings.
• Identify the OpenQASM version and required includes.
• Resolve parameters as required by the exporter.
• Retain required sidecars and their format versions.
• Parse with the intended consumer, not just a text editor.
• Compare relevant semantics on a small known example.
• Check the target device's gate set and execution constraints separately.

A syntactically accepted file is only one stage of portability. Device mapping, optimization, queueing, credentials and actual execution belong to additional stages. Successful export does not demonstrate an account connection, a paid hardware job or a measured quantum advantage.

Sources

• OpenQASM 3: A broader and deeper quantum assembly language, Cross and colleagues: motivation and language design.
• N/M documentation: the project's actual export workflow.
• N/M RFC archive: specific language and carrier contracts.
• Bell state with N/M: expected behavior of the example circuit.