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……………………………….
25635: (unnamed-fcode) [0xddf] 25636: (unnamed-fcode) [0xe04] 25637: (unnamed-fcode) [0xe38] 25638: (unnamed-fcode) [0xe06] 25639: (unnamed-fcode) [0xce5] 25640: (unnamed-fcode) [0xdb0] 25641: (unnamed-fcode) [0xe07] 25642: (unnamed-fcode) [0xe1a] 25643: (unnamed-fcode) [0xc5b] 25644: (unnamed-fcode) [0xe28] 25645: (unnamed-fcode) [0xe20] 25646: (unnamed-fcode) [0xdfa] 25647: (unnamed-fcode) [0xe37] 25648: (unnamed-fcode) [0xe2c] 25649: (unnamed-fcode) [0xe2d]
The next thing seems to be:
new-token ( 0x0b5 ) 0xddf 21913: b(:) ( 0x0b7 ) 21914: b(lit) ( 0x010 ) 0x10 21915: (unnamed-fcode) [0xdde] 21916: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c3] 21917: b(lit) ( 0x010 ) 0x14 21918: (unnamed-fcode) [0xdde] 21919: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c4] 21920: (unnamed-fcode) [0x9c0] 21921: b(lit) ( 0x010 ) 0xff 21922: and ( 0x023 ) 21923: (unnamed-fcode) [0xdde] 21924: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c6] 21925: b(lit) ( 0x010 ) 0x30 21926: (unnamed-fcode) [0xdde] 21927: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c5] 21928: (unnamed-fcode) [0x9bf] 21929: (unnamed-fcode) [0xa03] 21930: (unnamed-fcode) [0x9c5] 21931: (unnamed-fcode) [0xa04] 21932: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a5] 21933: (unnamed-fcode) [0x9bc] 21934: (unnamed-fcode) [0xa03] 21935: (unnamed-fcode) [0x9c3] 21936: (unnamed-fcode) [0xa04] 21937: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a3] 21938: (unnamed-fcode) [0x9c0] 21939: (unnamed-fcode) [0xa03] 21940: (unnamed-fcode) [0x9c6] 21941: (unnamed-fcode) [0xa04] 21942: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a6] 21943: (unnamed-fcode) [0x9bd] 21944: (unnamed-fcode) [0xa03] 21945: (unnamed-fcode) [0x9c4] 21946: (unnamed-fcode) [0xa04] 21947: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a4] 21948: (unnamed-fcode) [0xa3b] 21949: (unnamed-fcode) [0xa3d] 21950: (unnamed-fcode) [0xddd] 21951: b(;) ( 0x0c2 )
I don’t really understand this (unnamed-fcode) [0xddf], or any of the (unnamed-fcode)?
Could someone explain that to me.
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).
I don’t really understand this (unnamed-fcode) [0xddf], or any of the (unnamed-fcode)?
It is just a normal token. detok prints that funny verbose stuff if it doesn't have a name for the token (like if it was created with new-token).
Segher
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?
I don’t really understand this (unnamed-fcode) [0xddf], or any of the (unnamed-fcode)?
It is just a normal token. detok prints that funny verbose stuff if it doesn't have a name for the token (like if it was created with new-token).
Is there anyway to make detok be less verbose, and just print the raw Forth?
Segher
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On Tue, Dec 19, 2017 at 11:20:57AM -0500, 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?
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]").
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
On Dec 19, 2017, at 12:21 PM, Segher Boessenkool segher@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@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
On Tue, Dec 19, 2017 at 02:09:09PM -0500, Jd Lyons wrote:
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?
Yeah, something like that. I don't know if that will solve the problem, but it will solve _a_ problem.
Segher
On Dec 19, 2017, at 2:40 PM, Segher Boessenkool segher@kernel.crashing.org wrote:
On Tue, Dec 19, 2017 at 02:09:09PM -0500, Jd Lyons wrote:
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?
Yeah, something like that. I don't know if that will solve the problem, but it will solve _a_ problem.
True, we may as well make a few improvements to Openbios, if we can………
Tho I’m having trouble finding where read-fcode-offset is defined in SLOF.
https://github.com/dgibson/SLOF
Segher
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On Tue, Dec 19, 2017 at 02:44:49PM -0500, Jd Lyons wrote:
On Dec 19, 2017, at 2:40 PM, Segher Boessenkool segher@kernel.crashing.org wrote: On Tue, Dec 19, 2017 at 02:09:09PM -0500, Jd Lyons wrote:
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?
Yeah, something like that. I don't know if that will solve the problem, but it will solve _a_ problem.
True, we may as well make a few improvements to Openbios, if we can………
Tho I’m having trouble finding where read-fcode-offset is defined in SLOF.
Something similar in openbios is called fcode-offset .
Segher
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.
On Dec 22, 2017, at 6:11 AM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
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.
On Fri, Dec 22, 2017 at 11:11:45AM +0000, Mark Cave-Ayland wrote:
On 19/12/17 16:20, Jd Lyons wrote:
On Dec 19, 2017, at 10:56 AM, Segher Boessenkool segher@kernel.crashing.org wrote:
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?
No, but it is very suspicious.
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.
But that is the incorrect thing to do! A b?branch in interpret mode (with flag 0) should skip the following code, _not_ try to compile it.
It can be compiled from [IF] instead of IF for example (somewhat comparable to #if in C).
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.
Yup, more debugging would help.
Segher
-
Jd Lyons -
Mark Cave-Ayland -
Segher Boessenkool