I was also thinking about Jack debugger, though integrated with the VM emulator. My idea is to add debugging comments to the generated VM code. Things like line number and variable names are two of the more obvious things to add. With these, the VM emulator can load the .jack file, show the currently executed line, show the local, instance and class variables and their values, set breakpoints, etc.
Line number comments may be affected by some optimizations, so the compiler may decide to not apply them, when instructed to generate debug info.
Another option would be to extend the VM specs with pseudo-instructions, which add the debugging metadata, but I don't think it's the right option for Jack.
P.S. I don't know when I'll be able to work on this, but I'll be happy to keep compatibility with your implementation if possible.
Or maybe create a standalone debug file that contain debug info and symbols for each compiled executable? (like the PDB file for example for windows).
I am just thinking on how to start on this, and didn't commit to it yet. But will try to do it so it can be as portable as possible. That is this debugger should be capable of debugging a simulated Hack hardware too (much like debugging embedded hardware with Visual studio).
Are you trying to do in Java in a new gui? Something like a "Jack emulator"?
And then use the screen in the VM emulator as a display for the screen output?
Having the debug info in a separate file means, that the two may start to point to different versions. E.g. you compile once with debug info, make some changes, compile a second time, but forget to add the debug switch. The debugger will happily load the old debug file and show strange results.
Are there any advantages, which compensate this?
For the moment I haven't done anything regarding this. I was thinking about extending the current tools.
This turns out to be a non trivial task. To get jack on visual studio I have to first create a jack project type, have the editor recognize the jack syntax etc...
The debugger comes really last in this.
Just setting the environment to develop on is hard itself. (visual studio sdk, different VS versions etc...)
But I made some tiny progress and this drives me to keep on.