izaya/collapseos
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
7dc00179f7
collapseos/blk/398

13 lines
327 B
Plaintext
Raw Normal View History

Limit ourselves to 8-bit branching I'm planning on going back to 8-bit branching. 16-bit br cells incur a non-negligible penalty and, while at first 64 words (128 bytes forward or backward) seemed a bit limiting, I now don't see why one would ever construct such a big branch. It would be un-forthy. Also, I looked at using BC instead of IY to hold IP and the transition would be a lot easier with 8-bit branching. In this commit, all I do is add overflow checks in IF. The mechanic below doesn't change. I'll give myself some time to think it over so that I avoid yet another back and forth.
2020-05-24 10:01:46 -04:00
: IF ( -- a | a: br cell addr )
Make br cells 1 byte wide The 1 byte limitation has been effective for a while now, but I hadn't made the move yet, I wanted to see if the limitation would cause me problems. It doesn't. Doing this now slightly facilitates the IY->BC move in z80. Bootstrapping: if you try to recreate the CVM binary from the previous commit with this code, you'll have bootstrapping problems. The first bootstrap will compile a binary with 2-bytes wide cells but branching conditionals that yields 1-byte cells. That's bad. I got around the issue by temporarily inserting a "397 399 LOADR" instruction in cvm/xcomp.fs, right before the xcomp overrides. This way, I force 1-byte cells everywhere on the first compiliation, which then allows me to apply the logic change in cvm/vm.c and have a properly running binary.
2020-07-06 07:27:50 -04:00
0x3f ( ?br ) , H@ 1 ALLOT ( br cell allot )
Move Cross-compiled core from B390 to B350 and renamed it "Core words". Also, reworded the presentation.
2020-05-15 22:44:49 -04:00
; IMMEDIATE
Limit ourselves to 8-bit branching I'm planning on going back to 8-bit branching. 16-bit br cells incur a non-negligible penalty and, while at first 64 words (128 bytes forward or backward) seemed a bit limiting, I now don't see why one would ever construct such a big branch. It would be un-forthy. Also, I looked at using BC instead of IY to hold IP and the transition would be a lot easier with 8-bit branching. In this commit, all I do is add overflow checks in IF. The mechanic below doesn't change. I'll give myself some time to think it over so that I avoid yet another back and forth.
2020-05-24 10:01:46 -04:00
: THEN ( a -- | a: br cell addr )
Make br cells 1 byte wide The 1 byte limitation has been effective for a while now, but I hadn't made the move yet, I wanted to see if the limitation would cause me problems. It doesn't. Doing this now slightly facilitates the IY->BC move in z80. Bootstrapping: if you try to recreate the CVM binary from the previous commit with this code, you'll have bootstrapping problems. The first bootstrap will compile a binary with 2-bytes wide cells but branching conditionals that yields 1-byte cells. That's bad. I got around the issue by temporarily inserting a "397 399 LOADR" instruction in cvm/xcomp.fs, right before the xcomp overrides. This way, I force 1-byte cells everywhere on the first compiliation, which then allows me to apply the logic change in cvm/vm.c and have a properly running binary.
2020-07-06 07:27:50 -04:00
DUP H@ -^ _bchk SWAP ( a-H a ) C!
Move Cross-compiled core from B390 to B350 and renamed it "Core words". Also, reworded the presentation.
2020-05-15 22:44:49 -04:00
; IMMEDIATE
Limit ourselves to 8-bit branching I'm planning on going back to 8-bit branching. 16-bit br cells incur a non-negligible penalty and, while at first 64 words (128 bytes forward or backward) seemed a bit limiting, I now don't see why one would ever construct such a big branch. It would be un-forthy. Also, I looked at using BC instead of IY to hold IP and the transition would be a lot easier with 8-bit branching. In this commit, all I do is add overflow checks in IF. The mechanic below doesn't change. I'll give myself some time to think it over so that I avoid yet another back and forth.
2020-05-24 10:01:46 -04:00
: ELSE ( a1 -- a2 | a1: IF cell a2: ELSE cell )
Extract (br), (?br) and (loop)'s code out of stable ABI zone There is now no more actual code in stable ABI, only references. This makes refactoring of this code much easier. For example, changing IY to BC as the IP register.
2020-07-05 14:57:18 -04:00
0x3b ( br ) ,
Make br cells 1 byte wide The 1 byte limitation has been effective for a while now, but I hadn't made the move yet, I wanted to see if the limitation would cause me problems. It doesn't. Doing this now slightly facilitates the IY->BC move in z80. Bootstrapping: if you try to recreate the CVM binary from the previous commit with this code, you'll have bootstrapping problems. The first bootstrap will compile a binary with 2-bytes wide cells but branching conditionals that yields 1-byte cells. That's bad. I got around the issue by temporarily inserting a "397 399 LOADR" instruction in cvm/xcomp.fs, right before the xcomp overrides. This way, I force 1-byte cells everywhere on the first compiliation, which then allows me to apply the logic change in cvm/vm.c and have a properly running binary.
2020-07-06 07:27:50 -04:00
1 ALLOT
Limit ourselves to 8-bit branching I'm planning on going back to 8-bit branching. 16-bit br cells incur a non-negligible penalty and, while at first 64 words (128 bytes forward or backward) seemed a bit limiting, I now don't see why one would ever construct such a big branch. It would be un-forthy. Also, I looked at using BC instead of IY to hold IP and the transition would be a lot easier with 8-bit branching. In this commit, all I do is add overflow checks in IF. The mechanic below doesn't change. I'll give myself some time to think it over so that I avoid yet another back and forth.
2020-05-24 10:01:46 -04:00
[COMPILE] THEN
Make br cells 1 byte wide The 1 byte limitation has been effective for a while now, but I hadn't made the move yet, I wanted to see if the limitation would cause me problems. It doesn't. Doing this now slightly facilitates the IY->BC move in z80. Bootstrapping: if you try to recreate the CVM binary from the previous commit with this code, you'll have bootstrapping problems. The first bootstrap will compile a binary with 2-bytes wide cells but branching conditionals that yields 1-byte cells. That's bad. I got around the issue by temporarily inserting a "397 399 LOADR" instruction in cvm/xcomp.fs, right before the xcomp overrides. This way, I force 1-byte cells everywhere on the first compiliation, which then allows me to apply the logic change in cvm/vm.c and have a properly running binary.
2020-07-06 07:27:50 -04:00
H@ 1- ( push a. 1- for allot offset )
Move Cross-compiled core from B390 to B350 and renamed it "Core words". Also, reworded the presentation.
2020-05-15 22:44:49 -04:00
; IMMEDIATE
Reference in New Issue Copy Permalink