Blue Swirl wrote:
That's possible.
But I think the performance hit could be avoided almost entirely. Make non-debug and debug versions of "semis" and "docol". On startup construct the "words" table, while building select the non-debug versions, unless some magic diagnostic switch is on. "next" or "enterforth" may still need a test.
Maybe the switch to debug table could even happen during execution by user command.
Indeed. I had a similar inspiration earlier this evening, with the only problem being how to switch code into next() without causing a performance hit. However, I think I've just worked out a cute little hack that would solve this. I'm at a conference over the next few days, so it might not be until next week that I get a chance re-work the patch and resubmit.
In the meantime, I've looked again at the v2 patch I posted and I still can't work out why the debugging output by printk() doesn't appear on a VNC display for Qemu SPARC64, while it appears fine when Qemu SPARC64 is invoked in -nographic mode. Can anyone shed any light on this?
ATB,
Mark.