[OpenBIOS] PIC Passthough( VGA )

[Jd Lyons]

> On Dec 19, 2017, at 12:21 PM, Segher Boessenkool <segher at kernel.crashing.org> wrote:
> 
> On Tue, Dec 19, 2017 at 11:20:57AM -0500, Jd Lyons wrote:
>>> On Dec 19, 2017, at 10:56 AM, Segher Boessenkool <segher at kernel.crashing.org> wrote:
>>> On Tue, Dec 19, 2017 at 10:40:08AM -0500, Jd Lyons wrote:
>>>> Looks like the spot were I’m stuck is:
>>>> 
>>>> b(;) ( 0x0c2 ) 
>>>> 25612: b(') ( 0x011 ) (unnamed-fcode) [0xc84] 
>>>> 25613: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a9] 
>>>> 25614: (unnamed-fcode) [0xe34] 
>>>> 25615: (unnamed-fcode) [0xdff] 
>>>> 25616: (unnamed-fcode) [0x93d] 
>>>> 25617: b(lit) ( 0x010 ) 0xf
>>>> 25618: <> ( 0x03d ) 
>>>> 25619: b?branch ( 0x014 ) 0x0026 ( =dec 38)
>>>> 25620:     (unnamed-fcode) [0x9bd] 
>>>> 25621:     b(lit) ( 0x010 ) 0xff
>>>> 25622:     and ( 0x023 ) 
>>>> 25623:     my-space ( 0x103 ) 
>>>> 25624:     + ( 0x01e ) 
>>>> 25625:     (unnamed-fcode) [0xa08] 
>>>> 25626:     b(lit) ( 0x010 ) 0x6
>>>> 25627:     and ( 0x023 ) 
>>>> 25628:     b(lit) ( 0x010 ) 0x4
>>>> 25629:     = ( 0x03c ) 
>>>> 25630:     b?branch ( 0x014 ) 0x0009 ()
>>>> 25631:         b(') ( 0x011 ) (unnamed-fcode) [0x9c1] 
>>>> 25632:         b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c0] 
>>>> 25633:     b(>resolve) ( 0x0b2 ) 
>>>> 25634: b(>resolve) ( 0x0b2 ) 
>>>> 
>>>> It seems to break right here……………………………….
>>> 
>>> Those b?branch are in interpret mode, I don't know if that is handled
>>> correctly (it is tricky to get right).
>>> 
>> 
>> So, is it hanging at b(>resolve) ( 0x0b2 ) or (unnamed-fcode) [0xddf] ?
>> 
>> Do we need to work on how Openbios handles  b?branch?
> 
> That is my suspicion yes.
> 
> From fcode.fs:
> ===
> \ b?branch ( continue? -- )
> \   Conditional branch FCode. Followed by FCode-offset.
> 
> : b?branch
>  fcode-offset 0< if \ if we jump backwards, we can forsee where it goes
>    ['] do?branch ,
>    resolve-dest
>    execute-tmp-comp
>  else
>    setup-tmp-comp ['] do?branch ,
>    here 0
>    0 ,
>  then-
>  ; immediate
> ===
> 
> This is not compliant; it should behave differently in interpretation
> state (just skip stuff).  This matters if e.g. the stuff inside the "if"
> does not compile properly, etc. (it can be used to implement "[if]”)

Here’s how it handled in SLOF

: b?branch ( flag -- )
   ?compile-mode IF
      read-fcode-offset ?negative IF
         dest-on-top postpone until
      ELSE
         postpone if
      THEN
   ELSE
      ( flag ) IF
         fcode-offset jump-n-ip       \ Skip over offset value
      ELSE
         read-fcode-offset
         ?jump-direction jump-n-ip
      THEN
   THEN
; immediate

Do you think something like that would work Segher?

> .
> 

>> Is there anyway to make detok be less verbose, and just print the raw Forth?
> 
> It's a simple matter of coding ;-)
> 
> The thing is, those words do not have names in the compiled FCode.  The
> things I detokenised by hand I gave names like "xddf" which is friendlier;
> but your program might actually have names like that, too...
> 
> 
> Segher
> 
> -- 
> OpenBIOS                 http://openbios.org/ <http://openbios.org/>
> Mailinglist:  http://lists.openbios.org/mailman/listinfo <http://lists.openbios.org/mailman/listinfo>
> Free your System - May the Forth be with you

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/openbios/attachments/20171219/a8273b8d/attachment-0001.html>