Hopefully I'll get all the current opcodes implemented in the VM by the weekend, then I can work on the debugger. I've already found a few occasions that I'd want to cause a debug breakpoint, such as when you try to add an integer and a string, or something like that. DruinkScript won't coerce the variables directly, I'll add an opcode to do that for me. That should be more robust I think, and since I won't be writing assembly scripts often (If at all), it won't matter. It should also be faster than converting ints to strings and suchlike whenever I need. And means less code.
Stuff to do with the debugger:
- Support debug breakpoints, which will show the instruction that caused the break
- Allow viewing of the stack and registers
- Allow stepping through since instructions and chunks of instructions - For when the compiler is done and one statement may result in several instructions.
- Allow changing registers and variables, both the type and the value of them
- Support socket connections to the debugger server for remote debugging, and to allow a debugger to be a completely seperate application
I also finally remembered what the other preprocessor define was for compiling DruinkScript: DRUINKSCRIPT_NO_ERROR_STRINGS which removes the function for converting error codes to const char*'s. Pointless if the app isn't in English, or you're not going to display error strings anyway. I'll also need a preprocessor things for enabling / disabling the debugger.
That'll do for now. Back to work...
