simon987 / Much-Assembly-Required

Assembly programming game

Home Page:https://muchassemblyrequired.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Trap flag / Debugger

simon987 opened this issue · comments

(Brainstorm, wip, open to ideas)

  • Add a new debugger tab
    • memory hex view
    • registers
    • flags
    • Cubot status (health, shield, energy etc)
  • Add trap flag
    • (is not a real flag in Status.java)
    • Is set by INT 3
    • When enabled, calls INT1 after every instruction
  • When INT1 or INT3 is called, the special handler will stop execution until you manually press on the "step" or "continue" (which unsets trap flag) from the debugger tab.
  • When assembling, every instruction offset is mapped to a line number
  • When stepping through instructions, the line associated to IP is highlighted (and ideally scrolled into view)
  • Add editor shortcuts F8 to step, F9 to continue

Is it a problem that the player code could potentially be executing through a "tick boundary", e.g. while World states are updating or worse, during save(), asynchronous from the main game loop?
How to calculate execution time (in miliseconds) if a player is continuously stopping/resuming execution?
What happens at the beginning of a tick if a player's CPU is currently executing code (or is paused) ?

Possible solutions:

  • Have a set number of instructions allowed instead of time limit
    • That number is reset at the beginning of each tick
  • "step" or "continue" websocket requests are handled asynchronously from the main game loop
    • There is a lock around the "update" and "save" functions
    • The execution limits still apply
  • At the beginning of the tick, only execute the user's code if the CPU is neither PAUSED or EXECUTING
  1. I would agree to move towards limiting the instruction count instead of time.
  2. What about only allowing 1 step each tick? It would depend on the tick length if this becomes tedious or not, but it would constrain all execution inside ticks right?
  3. Hm, im not sure how it is handled now? As far as i know each tick is 100% synchronous right? I don't think you would want to introduce asynchronous execution into your game loop. It sounds cool, but it would introduce issues that would be really hard to debug right?