On 2017-Dec-29 00:40 , Jd Lyons wrote:
[...]
b(>resolve) ( 0x0b2 ) 
(unnamed-fcode) [0xddf]<————This calls the offset? 0xddf

new-token ( 0x0b5 ) 0xddf
  b(:) ( 0x0b7 ) 
      b(lit) ( 0x010 ) 0x10
      (unnamed-fcode) [0xdde] <——This calls the offset? 0xdde

new-token ( 0x0b5 ) 0xdde
 b(:) ( 0x0b7 ) 
      my-space ( 0x103 ) 
      + ( 0x01e ) 
      dup ( 0x047 ) 
      (unnamed-fcode) [0xa08]<—— this calls 0xa08

new-token ( 0x0b5 ) 0xa08
   b(:) ( 0x0b7 ) 
       b(") ( 0x012 ) ( len=9 )
            " config-l@"
       $call-parent ( 0x209 ) 
   b(;) ( 0x0c2 )

Ah! Seeing that structure, the sequence comes down to:

0x10 my-space + dup " config-l@" $call-parent

That looks different than the debug output which seemed to be showing a bunch of extraneous "and"s.

So this is reading the first BAR at PCI config space address 10.

It's calling config-l@ from the parent, because this is a word defined by the PCI node. The code looks entirely reasonable. The questions to pursue:
- What is the value of my-space at that time?
- What is the value of my-self at that time? (because $call-parent will use my-self to find my-parent and thus the pci instance).

If either of them has something questionable, that's what is blowing up, and we can track back to figure out what happened.