Warning, the examples with variables in this log are all wrong. This update explains: !!!!!!!!!!!!!!!!!!!! Update !!!!!!!!!!!!!!!!!!!! ! In log19.txt, I realize that my variable ! ! handling is wrong. Variables should leave ! ! their addresses on the stack, not their ! ! values! We need FETCH to get the value from ! ! the address! ! !!!!!!!!!!!!!!!!!!!! Update !!!!!!!!!!!!!!!!!!!! Two new words add to the word "compiler" abilities of the interpreter: IMMEDIATE sets the latest word to be "immediate" HIDE takes the next "word" of input, looks it up in the dictionary, and then sets that word to be hidden (via the word HIDDEN) HIDE seems the easiest to test, so we'll start with that: : emit2 EMIT EMIT ; 66 65 emit2 AB HIDE emit2 66 65 emit2 PARSE ERROR: 66 65 emit2 That worked: we get the parse error because emit2 has been hidden and is no longer found in the dictionary. The HIDDEN word used by HIDE actually toggles the hidden state, so can we call HIDE again to unhide the word? HIDE emit2 Program received signal SIGSEGV, Segmentation fault. code_HIDDEN () at nasmjf.asm:635 635 xor [edi], word F_HIDDEN ; Toggle the HIDDEN bit in place. Oh, ha ha, no, of course not. It's hidden, so HIDE can't find it (and since there's absolutely no error checking, we crash trying to toggle the bit in some random memory location). I guess we could use LATEST and HIDDEN to manually toggle it back, but I can't be bothered tonight. Onward to IMMEDIATE. : ab 66 65 EMIT EMIT ; IMMEDIATE : foo 1000 . ; foo foo 55 EMIT ; ^C Program received signal SIGINT, Interrupt. _WORD.skip_non_words () at nasmjf.asm:339 339 call _KEY ; get next key, returned in %eax Something went wrong. I had to Ctrl+C to end the program. It was merrily taking input, but nothing would execute, not even Ctrl+D to end the input and exit. Let's try that again and verify we're toggling the right word... (gdb) r Starting program: /home/dave/nasmjf/nasmjf (gdb) c Continuing. LATEST 4 + C@ . 6 LATEST 5 + C@ EMIT L Okay, just sanity checking LATEST - it points to a word with 6 letters in the name and starts with the letter "L" (it's LATEST itself). I'll define my 'ab' word again, try it out (it should print the letters "AB"), and check LATEST again... : ab 66 65 EMIT EMIT ; ab AB LATEST 4 + C@ . 2 LATEST 5 + C@ EMIT a IMMEDIATE ab Drat! Then it locked up again. So IMMEDIATE is definitely not working right. Next night: okay, let's see what's going on... (gdb) break code_IMMEDIATE Breakpoint 2 at 0x80494ec: file nasmjf.asm, line 1097. (gdb) c Continuing. : ab 66 65 EMIT EMIT ; ab AB IMMEDIATE Breakpoint 2, code_IMMEDIATE () at nasmjf.asm:1097 (gdb) p/x (int)var_LATEST $1 = 0x804e000 (gdb) x/10c (int)var_LATEST 0x804e000: ... 2 '\002' 97 'a' 98 'b' ... So that's right - LATEST points at word 'ab'... 1098 add edi, 4 ; Point to name/flags byte. 1099 xor byte [edi], F_IMMED ; Toggle the IMMED bit. (gdb) p/x $edi $2 = 0x804a6b0 That's a dead giveaway, the address in register edi should now be LATEST + 4. But it's actually the _address_ of LATEST + 4! (gdb) p/x (int)var_LATEST $3 = 0x804e000 It still takes me a bit before I see it... (gdb) disass 1099 No function contains specified address. (gdb) disass code_IMMEDIATE Dump of assembler code for function code_IMMEDIATE: 0x080494ec <+0>: mov edi,0x804a6ac <--- should be PTR 0x080494f1 <+5>: add edi,0x4 => 0x080494f4 <+8>: xor BYTE PTR [edi],0x80 0x080494f7 <+11>: lods eax,DWORD PTR ds:[esi] 0x080494f8 <+12>: jmp DWORD PTR [eax] End of assembler dump. I finally see it. I have mov edi, var_LATEST where I should have mov edi, [var_LATEST] (so of course it wasn't working after that. LATEST was incremented and no longer pointed at word. All further interpretation would fail to match!) With that fixed, it should work... (gdb) load (gdb) r Starting program: /home/dave/nasmjf/nasmjf : ab 66 65 EMIT EMIT ; ab AB IMMEDIATE So now 'ab' should execute as soon as the interpreter sees it, even in compile mode: : five 5 . ab ; AB five 5 Yeah! The call to 'ab' executed at "compile time" rather than "run time" for the new word 'five'. Using this, we could add new language features to FORTH in FORTH. Next, the TICK (single quote ') word gets the address of a word (supplied after the ' so it doesn't execute. this is the same trick LIT uses). This implementation can only work at compile time because the interpreter needs to turn the word that follows as a 4-byte address for ' to be able to read and then hope over that value. Just for fun, let's try to print the address of the EMIT word outside of the compile state: ' EMIT . Program received signal SIGSEGV, Segmentation fault. See? Now let's use it the same way, but in a new compiled word: : addrofemit ' EMIT . ; addrofemit 134521260 Looks like it worked, but is that address correct? (gdb) info addr EMIT Symbol "EMIT" is at 0x804a1ac in a file compiled without debugging. (gdb) p/d 0x804a1ac $1 = 134521260 Yup! Then the next night, I've got a really exciting one, BRANCH0. But first, I'm trying to figure out how to even test BRANCH, let alone its conditional big brother! I even worked it out on paper the next morning, and I'm still not seeing why this doesn't work: : foo 65 EMIT BRANCH -12 ; foo A Program received signal SIGSEGV, Segmentation fault. code_BRANCH () at nasmjf.asm:27 27 lodsd ; NEXT: Load from memory into eax, inc esi to point to next word. By my calculations, esi starts off pointing at the offset number's instruction (-12), then we should be branching back to "65": 0 "-12" -4 BRANCH -8 EMIT -12 "65" And I've had a bummer of a time trying to step through it by breaking on BRANCH because that word is used (correctly) as part of the interpreter loop. So I'm going to copy BRANCH with the silly name BRUNCH and see why it's not correct! DEFCODE "BRUNCH",6,,BRUNCH add esi, [esi] NEXT Should be pretty simple, right? It's just a one-liner! (gdb) break code_BRUNCH (gdb) c Continuing. : foo 65 EMIT BRUNCH -12 ; foo A Breakpoint 2, code_BRUNCH () at nasmjf.asm:251 251 add esi, [esi] ; add the offset to the instruction pointer Okay, now let's thoroughly examine this. We're going to add the negative number stored where esi points to FROM esi. Where does esi point? (gdb) p/x $esi $3 = 0x804e01c (gdb) x/x $esi 0x804e01c: 0x0804a0f0 (gdb) info sym *$esi LIT in section .data of /home/dave/nasmjf/nasmjf (gdb) x/b $esi+4 0x804e020: -12 '\364' Yup, we can see that esi points to the address of LIT followed by the value -12. As expected. (gdb) s 27 lodsd ; NEXT: Load from memory into eax, inc esi to point to next word. Now that's run, where does esi point now? (gdb) info sym *$esi Cannot access memory at address 0x1009810c (gdb) p/x $esi $4 = 0x1009810c What? That address isn't right. It should be 12 less than before, not...oh wait... (gdb) disass code_BRUNCH Dump of assembler code for function code_BRUNCH: 0x08049054 <+0>: add esi,DWORD PTR [esi] => 0x08049056 <+2>: lods eax,DWORD PTR ds:[esi] 0x08049057 <+3>: jmp DWORD PTR [eax] End of assembler dump. Now I see it. We subtracted the address of LIT, not the -12 that follows it. No wonder I got a segfault. So how do I get the value -12 right after BRANCH? Next night: okay, so I reviewed the ported words so far and I'm pretty sure COMMA (,) fits the bill. It "compiles" the value on the stack to the current position... : foo 65 EMIT BRUNCH -12 , ; foo A Breakpoint 3, code_BRUNCH () at nasmjf.asm:251 251 add esi, [esi] ; add the offset to the instruction pointer (gdb) x/x **$esi 0x8049228 : 0xffad50ad ...no, dang it, that doesn't work either, and for the same reason. Sure, ',' will store whatever's on the stack, but we're still getting LIT -12 compiled first when we're compiling. So I really don't see any easy way to test BRANCH, let alone 0BRANCH with an arbitrary snippet of code at this point. :-( Next evening: I've also just ported LITSTRING and TELL, two more primitives that appear hard to test because I'm not sure how to compile literal values into memory yet. So, this would be a pretty big let-down way to end a log file but... IT APPEARS THAT I'VE PORTED ALL OF THE ASSEMBLY! Yeah, so starting with the next log, I'm going to start feeding jonesforth.f, which is the second half of the language implementation implemented in itself, into my port and fix the inevitable bugs. It's been about six months of slowly chipping away at this port nearly every single evening. I can barely believe this stage has arrived. This is so cool. 8-)