On 20/06/15 12:47, Mark Cave-Ayland wrote:
On 18/06/15 23:36, Mark Cave-Ayland wrote:
Otherwise the Forth intepreter fails due to lack of buffer space when trying to execute large boot scripts on platforms that use CR instead of LF for line endings (particularly MacOS 9).
Signed-off-by: Mark Cave-Ayland mark.cave-ayland@ilande.co.uk
openbios-devel/forth/bootstrap/interpreter.fs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/openbios-devel/forth/bootstrap/interpreter.fs b/openbios-devel/forth/bootstrap/interpreter.fs index 5187058..74a109f 100644 --- a/openbios-devel/forth/bootstrap/interpreter.fs +++ b/openbios-devel/forth/bootstrap/interpreter.fs @@ -163,7 +163,7 @@ defer outer-interpreter : evaluate ( str len -- ?? ) 2dup + -rot over + over do
- i c@ 0a = if
- i c@ dup 0a = swap 0d = or if i over - (evaluate) i 1+
While this seems to be correct, further testing shows that yaboot (which has some embedded \r codes in its Forth strings) emits warnings on the console with this patch applied. Will dig a bit deeper to try and figure out what is going on here.
So the real problem here appears to be that the OS 9 bootscript is using the rstack in order to store temporary variables. Since the Forth version of interpret is based in a loop which looks up each word in turn and then runs execute, the manipulation of the rstack with r> confuses the loop causing it to drop out early.
Actually I'm surprised we got as far as we did, however the OpenBIOS version of the execute word has a trampoline and combined with the fact that the OS 9 script has a CR just before the use of r> I think we were just extremely lucky.
I think the real solution here is to evaluate the Forth string in compile mode to an anonymous word in the dictionary and then execute it directly, but I'd welcome any other ideas.
ATB,
Mark.