On Apr 16, 2016, at 9:34 PM, Tarl Neustaedter wrote:
On 2016-Apr-16 21:07 , Programmingkid wrote:
After looking at the bootscript, I think return stack trashing is not a problem. There are three calls to >r and then three calls the r>. They balance each other out. To show that this is ok, just run this program:
: main 1 2 3 \ place these numbers on the stack
r r r
." doing something" cr r> r> r> ." You should see 3 2 1: " . . . cr ;
You will see at the end 3 2 1.
The above is guaranteed to work, it's all inside a colon definition (which means it's compiled as a whole before executing). The issue comes up when commands using the return stack are used outside colon definitions. E.g., at the ok prompt or in a boot-script string:
ok 3 >r ok <do some fancy parsing> ok r> .
I see what you mean.
If the parser uses the return stack itself, it might reset the stack before returning to the ok prompt, causing the third line to do something unexpected. In the case of Sun's OBP, when parsing things at the ok prompt, if something issued a "throw", the return stack would be reset to empty before returning to the ok prompt. I don't know what cases the Openbios parser might do something similar.
It might be the case that the parser doesn't use the return stack. If that is the case, we don't have to worry about this issue.
If using the return stack is suppose to cause problems when in boot-script reading mode, why does Mac OS 9 successfully boots?
[boot-script-container stuff to try to separate compiling from executing forth]
I really like this idea.
It's worth trying to see it gives us further insight on what's going on. If it's a problem with "here" being used by both the code and the parser and overwriting each other, the pre-compile will prevent the problem from occurring by separating the two usages. Good luck!
Seeing that the EOL character is required by the specs, I just don't see a need to do this anymore. It looks like your research has solved the problem. Also doesn't code executing in a colon definition behave differently than it would in interpretation mode?