Re: [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

PATCH: Implement Forth source debugger for OpenBIOS

[Mark Cave-Ayland]

Laurent Vivier wrote:
> > 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;
> }

Yeah, I did consider that this might be the case but it still doesn't 
seem to make sense looking at the code. The source for the forth emit 
word can be found in kernel/forth.c:

/*
  *   emit       ( char --  )
  */

static void emit(void)
{
#ifndef FCOMPILER
         cell tmp = POP();
         putchar(tmp);
#else
         (void) POP();
#endif
}

while for SPARC64 the source for printk() can be found in 
arch/sparc64/lib.c:

/* Format a string and print it on the screen, just like the libc
  * function printf.
  */
int printk( const char *fmt, ... )
{
         char *p, buf[512];
         va_list args;
         int i;

va_start(args, fmt);
         i = vsnprintf(buf, sizeof(buf), fmt, args);
         va_end(args);

for( p=buf; *p; p++ )
                 putchar(*p);
         return i;
}

Both of these use putchar() in order to write characters out to the 
console, and yet one of them works in a graphical terminal and one of 
them doesn't...

ATB,

Mark.