On 07/05/18 01:12, Joe van Tunen wrote:
It is unclear to me if the exception is caused by compiling the fcode or interpreting (executing) it. Your verbose output (which I'm unfamiliar with) shows only "(compile)". Without trying it myself or looking at Apple's byte-load code, I'm guessing that's some kind of context, and perhaps there's an interpret (execute) context? Can you send the full output directly to me or post a link?
Can you check the value of "here" before byte-load and after the exception to see how much dictionary space was used? I wonder if an exception would cause a rewind of some kind, or just leave everything as is.
The fcode in question is at the top level and looks like this:
new-token 0xe38 b(:) ... b(;) b(') (unnamed-fcode) [0xc84] b(to) (unnamed-fcode) [0x9a9] (unnamed-fcode) [0xe34] (unnamed-fcode) [0xdff] (unnamed-fcode) [0x93d] b(lit) 0xf <> b?branch 0x0026 ( =dec 38) (unnamed-fcode) [0x9bd] b(lit) 0xff and my-space + (unnamed-fcode) [0xa08] b(lit) 0x6 and b(lit) 0x4 = b?branch 0x0009 () b(') (unnamed-fcode) [0x9c1] b(to) (unnamed-fcode) [0x9c0] b(>resolve) b(>resolve) (unnamed-fcode) [0xddf] ...
Since it's at the top level, it probably must be getting executed. The problem might be in executing 0xddf (defined earlier in the fcode).
Once I get my fcode token to forth converter updated (so it can be used with Unix/macOS instead of MPW) then you can make your own nvidia open firmware driver with added debugging code.
You should look at the 1275.pdf document "IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices" to get a description of the tokens. "b?branch ... b(>resolve)" are the tokens for the forth "if ... then" statements (when the b?branch fcode offset is positive). The document also describes how a token behaves while the fcode evaluator is in interpretation state and compilation state.
Right. The Solaris 64-bit FCode bootloader is hugely complex, and getting this to execute in OpenBIOS fixed several bugs in the b?branch/b(>resolve) area so I'd be surprised (although its not impossible) if this were a bug there.
It would say it's much more likely the OpenBIOS is missing a word present in real OF somewhere in the FCode but it's difficult to see.
Have you tried using the OpenBIOS detok utility to dump out the FCode? (see https://github.com/openbios/fcode-utils).
ATB,
Mark.