izaya/collapseos
1
0
Fork 0
mirror of https://github.com/hsoft/collapseos.git synced 2024-11-21 04:38:05 +11:00
Code Issues Releases Wiki Activity
68dd800bd1
collapseos/blk/398

13 lines
325 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-25 00:01:46 +10:00
: IF ( -- a | a: br cell addr )
De-stabilize (br), (?br), (loop), (s) When writing the xcomp documentation, I realized that with careful threading and by accepting a bit of code duplication in the xcomp toolset, I could de-stabilize a couple of words. (n) and EXIT are a bit trickier, but I think it can be done. It would be nice to get rid of stable wordrefs...
2020-09-20 03:54:01 +10:00
COMPILE (?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-16 12:44:49 +10: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-25 00:01:46 +10: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 21:27:50 +10: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-16 12:44:49 +10: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-25 00:01:46 +10:00
: ELSE ( a1 -- a2 | a1: IF cell a2: ELSE cell )
De-stabilize (br), (?br), (loop), (s) When writing the xcomp documentation, I realized that with careful threading and by accepting a bit of code duplication in the xcomp toolset, I could de-stabilize a couple of words. (n) and EXIT are a bit trickier, but I think it can be done. It would be nice to get rid of stable wordrefs...
2020-09-20 03:54:01 +10:00
COMPILE (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 21:27:50 +10: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-25 00:01:46 +10: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 21:27:50 +10: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-16 12:44:49 +10:00
; IMMEDIATE
Reference in New Issue Copy Permalink