Hi everyone,
This patch fixes the b(do)...b(leaves)...b(loop)/b(+loop) structures by marking them as immediate rather then compile-only. Without this in place, the loop addresses would be calculated incorrectly which would cause the Fcode evaluator to jump to the wrong location for each loop iteration. I've confirmed that this change does not break do...leaves...loop in immediate mode either.
For reference, here are the test cases I used:
\ Test Fcode do...loop \ Forth: 3 0 do i . cr loop here cc c, \ offset16 a8 c, \ 3 a5 c, \ 0 17 c, 00 c, 08 c, \ b(do) 19 c, \ i 9d c, \ . 92 c, \ cr 15 c, ff c, fc c, \ b(loop) 00 c, \ end
\ Test Fcode do...+loop \ Forth: 10 0 do i . cr 2 +loop here cc c, \ offset16 10 c, 00 c, 00 c, 00 c, 10 c, \ b(lit) 0x10 a5 c, \ 0 17 c, 00 c, 09 c, \ b(do) 19 c, \ i 9d c, \ . 92 c, \ cr a7 c, \ 2 16 c, ff c, fb c, \ b(+loop) 00 c, \ end
\ Test Fcode do...leave...loop \ Forth: a 0 do i dup . 3 = if leave then loop here cc c, \ offset16 10 c, 00 c, 00 c, 00 c, 0a c, \ b(lit) 0xA a5 c, \ 0 17 c, 00 c, 0f c, \ b(do) 19 c, \ i 47 c, \ dup 9d c, \ . a8 c, \ 3 3c c, \ = 14 c, 00 c, 04 c, \ b?branch 1b c, \ b(leave) b2 c, \ b(>resolve) 15 c, ff c, f5 c, \ b(loop) 00 c, \ end
With these last 2 patches and diag-switch? set to true, the Fcode evaluator will now finish executing my SPARC64 disk image without crashing giving the following output:
OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on May 21 2009 19:09 Type 'help' for detailed information
[sparc64] Booting file 'disk' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 5936 bytes entry point is 0x4000 Evaluating FCode... reserved fcode word. Loading package 1.4 04 Aug 1995 13:02:54. reserved fcode word. reserved fcode word. reserved fcode word. FCode UFS Reader 1.12 00/07/17 15:48:16. Loading: /platform//ufsboot Loading: /platform/sun4u/ufsboot Boot load failed.
byte-load: stack overflow, diff -2
0 >
It looks as if the next stage is to implement the missing push-package/pop-package forth words to ensure that the ufs-file-system package is located at the correct point in the tree - I'll see if I can come up with something over the next few days.
ATB,
Mark.
On 21.05.2009 21:28 Uhr, Mark Cave-Ayland wrote:
Hi everyone,
This patch fixes the b(do)...b(leaves)...b(loop)/b(+loop) structures by marking them as immediate rather then compile-only. Without this in place, the loop addresses would be calculated incorrectly which would cause the Fcode evaluator to jump to the wrong location for each loop iteration. I've confirmed that this change does not break do...leaves...loop in immediate mode either.
For reference, here are the test cases I used:
\ Test Fcode do...loop \ Forth: 3 0 do i . cr loop here cc c, \ offset16 a8 c, \ 3 a5 c, \ 0 17 c, 00 c, 08 c, \ b(do) 19 c, \ i 9d c, \ . 92 c, \ cr 15 c, ff c, fc c, \ b(loop) 00 c, \ end
\ Test Fcode do...+loop \ Forth: 10 0 do i . cr 2 +loop here cc c, \ offset16 10 c, 00 c, 00 c, 00 c, 10 c, \ b(lit) 0x10 a5 c, \ 0 17 c, 00 c, 09 c, \ b(do) 19 c, \ i 9d c, \ . 92 c, \ cr a7 c, \ 2 16 c, ff c, fb c, \ b(+loop) 00 c, \ end
\ Test Fcode do...leave...loop \ Forth: a 0 do i dup . 3 = if leave then loop here cc c, \ offset16 10 c, 00 c, 00 c, 00 c, 0a c, \ b(lit) 0xA a5 c, \ 0 17 c, 00 c, 0f c, \ b(do) 19 c, \ i 47 c, \ dup 9d c, \ . a8 c, \ 3 3c c, \ = 14 c, 00 c, 04 c, \ b?branch 1b c, \ b(leave) b2 c, \ b(>resolve) 15 c, ff c, f5 c, \ b(loop) 00 c, \ end
With these last 2 patches and diag-switch? set to true, the Fcode evaluator will now finish executing my SPARC64 disk image without crashing giving the following output:
OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on May 21 2009 19:09 Type 'help' for detailed information
[sparc64] Booting file 'disk' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 5936 bytes entry point is 0x4000 Evaluating FCode... reserved fcode word. Loading package 1.4 04 Aug 1995 13:02:54. reserved fcode word. reserved fcode word. reserved fcode word. FCode UFS Reader 1.12 00/07/17 15:48:16. Loading: /platform//ufsboot Loading: /platform/sun4u/ufsboot Boot load failed.
byte-load: stack overflow, diff -2
0 >
It looks as if the next stage is to implement the missing push-package/pop-package forth words to ensure that the ufs-file-system package is located at the correct point in the tree - I'll see if I can come up with something over the next few days.
Can you run this with "true to ?fcode-verbose"? I wonder what those reserved fcode words are.
Stefan
Stefan Reinauer wrote:
Can you run this with "true to ?fcode-verbose"? I wonder what those reserved fcode words are.
Sure. As I mentioned in the previous email, it is the push-package/pop-package functions which are missing. I found a reference to those functions here: http://playground.sun.com/1275/proposals/Closed/Accepted/215-it.txt.
From reading this I think it's just a case of maintaining a stack of phandles, but I'm still quite new to Forth. If you think you could come up with something reasonably quickly, I'd be happy to test it. Otherwise I'll see if I can come up with something myself.
ATB,
Mark.
On 5/21/09, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Hi everyone,
This patch fixes the b(do)...b(leaves)...b(loop)/b(+loop) structures by marking them as immediate rather then compile-only. Without this in place, the loop addresses would be calculated incorrectly which would cause the Fcode evaluator to jump to the wrong location for each loop iteration. I've confirmed that this change does not break do...leaves...loop in immediate mode either.
For reference, here are the test cases I used:
\ Test Fcode do...loop \ Forth: 3 0 do i . cr loop here cc c, \ offset16 a8 c, \ 3 a5 c, \ 0 17 c, 00 c, 08 c, \ b(do) 19 c, \ i 9d c, \ . 92 c, \ cr 15 c, ff c, fc c, \ b(loop) 00 c, \ end
\ Test Fcode do...+loop \ Forth: 10 0 do i . cr 2 +loop here cc c, \ offset16 10 c, 00 c, 00 c, 00 c, 10 c, \ b(lit) 0x10 a5 c, \ 0 17 c, 00 c, 09 c, \ b(do) 19 c, \ i 9d c, \ . 92 c, \ cr a7 c, \ 2 16 c, ff c, fb c, \ b(+loop) 00 c, \ end
\ Test Fcode do...leave...loop \ Forth: a 0 do i dup . 3 = if leave then loop here cc c, \ offset16 10 c, 00 c, 00 c, 00 c, 0a c, \ b(lit) 0xA a5 c, \ 0 17 c, 00 c, 0f c, \ b(do) 19 c, \ i 47 c, \ dup 9d c, \ . a8 c, \ 3 3c c, \ = 14 c, 00 c, 04 c, \ b?branch 1b c, \ b(leave) b2 c, \ b(>resolve) 15 c, ff c, f5 c, \ b(loop) 00 c, \ end
With these last 2 patches and diag-switch? set to true, the Fcode evaluator will now finish executing my SPARC64 disk image without crashing giving the following output:
OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on May 21 2009 19:09 Type 'help' for detailed information
[sparc64] Booting file 'disk' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 5936 bytes entry point is 0x4000 Evaluating FCode... reserved fcode word. Loading package 1.4 04 Aug 1995 13:02:54. reserved fcode word. reserved fcode word. reserved fcode word. FCode UFS Reader 1.12 00/07/17 15:48:16. Loading: /platform//ufsboot Loading: /platform/sun4u/ufsboot Boot load failed.
byte-load: stack overflow, diff -2
0 >
Nice progress. marTux 0.2 still crashes at the same point: entry point is 0x4000 Evaluating FCode... reserved fcode word. Loading package 1.4 04 Aug 1995 13:02:54. reserved fcode word. reserved fcode word. reserved fcode word. FCode UFS Reader 1.13 05/06/08 08:30:31. Unhandled Exception 0x0000000000000034 PC = 0x00000000ffd0e370 NPC = 0x00000000ffd0e374 Stopping execution
I still applied this (r492), thanks.
-
Blue Swirl -
Mark Cave-Ayland -
Stefan Reinauer