[OpenBIOS] PATCH: Implement Forth source debugger for OpenBIOS

[Laurent Vivier]

>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
-- 
--------------------- Laurent at vivier.eu  ---------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard