munich-quantum-toolkit / munich-quantum-toolkit/debugger

:recycle: Separate Simulation, Debugging and Diagnostics concerns further

Open
#6 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

c++ enhancement
Dominant language
C++
Stars
21
Forks
7
Avg merge
9h 28m
Merged PRs (30d)
42

Description

What's the problem this feature will solve?

Currently, the debugging backend is separated into two interfaces:
debug.h and diagnostics.h. However, this separation is not perfect.

  • For the DD implementation in particular, many diagnostics concerns are still stored in the DDSimulationState and only the actual methods and functionalities are located in DDDiagnostics. These fields should be moved

Furthermore, a third simulation interface would make sense. Currently, if we want to change to a new simulation backend, a large number of different functions have to be re-implemented, even though they can be expressed through different functions. For instance, all the "step over", "step out", "run simulation" functions can be expressed using just the "step forward" method and "getCurrentInstruction". It would be nice to separate these so that changing the simulation backend only requires a few functions to be changed.

Describe the solution you'd like

Three interfaces:

  • debug.h: Contains debugging-related functions, like checking assertions, running up to specific points in the code, or getting the stack trace
  • simulation.h: Only contains low-level simulation features, like stepping forward, backward, etc.
  • diagnostics.h: Contains all functions related to analysing the program.

Their DD-based implementations should also be separated more clearly, and, if possibly, with only minimal coupling to the actual language used (such as OpenQASM)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the existing debug.h and diagnostics.h interfaces, especially which diagnostic fields live in DDSimulationState and which methods are in DDDiagnostics. Map the proposed simulation.h responsibilities and how step-forward and getCurrentInstruction could support higher-level operations. Done means the three interfaces and their DD implementations are separated with minimal coupling to OpenQASM.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
devtools
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.