Trap flag / Debugger
simon987 opened this issue · comments
simon987 commented
(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
- (is not a real flag in
- 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
Kevin Ramharak commented
- I would agree to move towards limiting the instruction count instead of time.
- 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?
- 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?