On 5/9/18, 7:07 AM, "Segher Boessenkool" segher@kernel.crashing.org wrote:
On Wed, May 09, 2018 at 08:27:14AM -0400, Jd Lyons wrote: > Bear with me, while I try to understand this, but it looks like b?branch sets up some type of temporary buffer, and b(>resolve) try to “flush” that buffer.
Yes; and that is incorrect. b?branch in interpret mode is only allowed for forward branches (which you have here), and it should simply skip that much forward (in the fcode stream) if the top of stack was 0. Not compile anything.
The code in OpenBIOS is currently doing it differently. Someone put some effort in making it this way (though README.device says fcode.fs is partly untested). Before changing it, it should be proven that it can't work that way. This current method means all the bytes in the fcode stream are processed in some way.
On May 9, 2018, at 4:55 AM, Jd Lyons via OpenBIOS mailto:openbios@openbios.org wrote:
I don’t know if this is helpful, but I did a debug of b?branch and b(>resolve):
The output is missing the changes you made to (debug-feval). What did you do to get that debug output? Did you just follow the instructions from README.debugger with b?branch and b(>resolve)? The debug output doesn't show what the second execute-tmp-comp is executing (the first execute-tmp-comp does nothing since depth hasn't returned to tmp-comp-depth yet). I don't see anything wrong with the debug output that you have so far. I think you need to look at debugging all the fcodes after the first b?branch. Can you do a debug trace of execute-tmp-comp?
Just deleting the b(>resolve) I’m hanging on and replacing it with ff gets a little further, and what I’m thinking is these two b(>resolves) and the two b?branch that come before them have something to do with the children, NVDA,Display-A and NVDA,Display-B. Maybe something to do with display detection, or the set-mode command.
If there's a problem with b?branch, then you shouldn't be using the nvidia rom to test it - use a simplified fcode image instead.
ff is the fcode for end1, but that does nothing while in compile mode. OpenBIOS won't leave compile mode started by b?branch without a corresponding b(>resolve), and it eventually exceeds the temporary compile buffer size, trashing the dictionary, and then causing a hang. Maybe OpenBIOS needs a guard against that? "here!" should probably take two values, the new "here" value and a "limit". Then anything that adds to the dictionary should use that new limit instead of the usual limit.
Get-mode, show-mode, and set-mode are called twice, I assume once for each display node, so something is going wrong with NVDA,Dispaly-A/B, I just don’t know what it is.
They are not executed, because OpenBIOS hasn't left compile mode, because you removed (b>resolve).
On 5/9/18, 11:34 AM, "Mark Cave-Ayland" mark.cave-ayland@ilande.co.uk wrote:
I'm confused here: b?branch is FCode-only and executed as part of the FCode evaluation. The tmp-comp-buf is used to hold the xts derived from the FCode token stream until the point where the branch is resolved.
However I still think for the moment we're digging way to deep here...
I agree. We haven't proved there's anything wrong with b?branch (except that the size of the temporary compile buffer could be exceeded but that's not the problem with the nvidia rom). Running that test fcode image that I mentioned would probably have shown that it works.
On 5/9/18, 11:45 AM, "OpenBIOS on behalf of Mark Cave-Ayland" <openbios-bounces@openbios.org on behalf of mark.cave-ayland@ilande.co.uk> wrote:
I suspect that it's something within that branch failing which is only visible at the final b(>resolve) once the condition is evaluated, so with indentation:
...
Most of that looks fairly normal, so I'd start by looking at the 0x9bd and 0xa08 FCodes which will have been generated further up in your output file.
I suspect you'll end up converting chunks of FCode back into Forth to figure out which part is failing.
I think a debug trace of execute-tmp-comp might work to get to what part of 0x9bd or 0xa08 is causing the exception?