On 19/12/17 16:20, Jd Lyons wrote:
On Dec 19, 2017, at 10:56 AM, Segher Boessenkool segher@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?
Are you sure that b?branch is the culprit here? A b?branch...b(>resolve) is a representation of a if() { ... } block which means as soon as you hit the b(>resolve) then you execute the contents of the buffer generated between b?branch and b(>resolve) if you match the condition.
Now the Solaris/SPARC boot blocks do some really crazy stuff in Forth which to the best of my knowledge flushed out all the FCode branch bugs - not that there couldn't be a bug remaining, but it's much more likely that something in the b?branch...b(>resolve) is throwing an exception.
ATB,
Mark.