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.
The changes I made to Openbios b?(branch) and later b(>resolve) resulted in system hangs in the Fcode, before the offset I was getting to before. So it’s really tricky, I know the nVida Rom reads some resisters on the card and reads an and/or mask at 0x58 in the Rom, then calculates some stuff for the NVDA,BMP. I’m not sure I’m even getting to that point it the code. Just from running the debug word on b?branch and b(>resolve) that are quite a few calls to it in the Rom before I hit the exception point, and Openbios seems to handle those fine, until “us” is called, then things seem to fall apart.
b(>resolve) seems to be really tricky, as changes I made there resulted in no input or output devices unless booted with -noghrphic, and trying to boot the Mac OS resulted in an out of bounds Rom/Ram exception.
I’m thinking it maybe a timebase issue, and that code in both Openbios and Qemu-PPC seems to need a little work anyway. If we can come up with some better methods of calculation : ms and : us that may help the issue, or may not, but we’ll likely end up with a little better emulator, so that’s the fun part.
ATB,
Mark.