a7dcb522c2
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.
17 lines
692 B
Plaintext
17 lines
692 B
Plaintext
: OP1 CREATE C, DOES> C@ A, ;
|
|
0xc3 OP1 RETn, 0xfa OP1 CLI, 0xfb OP1 STI,
|
|
0xf4 OP1 HLT, 0xfc OP1 CLD, 0xfd OP1 STD,
|
|
0x90 OP1 NOP, 0x98 OP1 CBW,
|
|
0xf3 OP1 REPZ, 0xf2 OP1 REPNZ, 0xac OP1 LODSB,
|
|
0xad OP1 LODSW, 0xa6 OP1 CMPSB, 0xa7 OP1 CMPSW,
|
|
0xa4 OP1 MOVSB, 0xa5 OP1 MOVSW, 0xae OP1 SCASB,
|
|
0xaf OP1 SCASW, 0xaa OP1 STOSB, 0xab OP1 STOSW,
|
|
( no argument, jumps with relative addrs are special )
|
|
0xeb OP1 JMPs, 0xe9 OP1 JMPn, 0x74 OP1 JZ,
|
|
0x75 OP1 JNZ, 0x72 OP1 JC, 0x73 OP1 JNC,
|
|
0xe8 OP1 CALLn,
|
|
|
|
: OP1r CREATE C, DOES> C@ + A, ;
|
|
0x40 OP1r INCx, 0x48 OP1r DECx,
|
|
0x58 OP1r POPx, 0x50 OP1r PUSHx,
|