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?
Because "printk()" are sent to serial and must use only for debug purpose. You must use forth words like "emit" or "type" to send characters to display. For instance, look at "modules/cmdline.c":
static void emit( int ch ) { PUSH( ch ); fword("emit"); }
static int emit_str( const char *str ) { int n = 0; while( *str ) { n++; emit( *str++ ); } return n; }
I think we could use also a "fword(type)" instead of the "emit_str()" (see forth/bootstrap/bootstrap.fs).
Regards, Laurent