colorful rat Ratfactor.com > Dave's Repos

nasmjf

A NASM assembler port of JONESFORTH
git clone http://ratfactor.com/repos/nasmjf/nasmjf.git

nasmjf/devlog/log08.txt

Download raw file: devlog/log08.txt

1 Now there are a bunch of problems. 2 3 CREATE should be creating the next link in our linked 4 list of words (the dictionary). The link should point 5 to the most recent word defined (LATEST) and should be 6 put wherever HERE points (that's the free space where we 7 can compile new words). 8 9 Well, I haven't set up the space HERE points to yet, so 10 that's probably the next thing I should do. 11 12 Then it looks like I've got a typo where I should be getting 13 the address STORED at var_HERE, not the address of var_HERE 14 itself. 15 16 Same with var_LATEST - they should both be [FOO] instead 17 of FOO. Silly late night transcription mistakes. 18 19 Finally, the address I'm attempting to store is clearly 20 getting truncated: 0x0804a3bc becomes 0x0000a3bc. 21 22 (gdb) break code_CREATE 23 Breakpoint 2 at 0x8049235: file nasmjf.asm, line 535. 24 (gdb) c 25 Continuing. 26 : FIVE 5 ; 27 28 Breakpoint 2, code_CREATE () at nasmjf.asm:535 29 535 pop ecx ; length of word name 30 536 pop ebx ; address of word name 31 539 mov edi, var_HERE ; the address of the header 32 540 mov eax, var_LATEST ; get link pointer 33 (gdb) x/x &var_LATEST 34 0x804a3bc <var_LATEST>: 0x0804a3ac 35 (gdb) info symb (int)var_LATEST 36 name_LATEST in section .data of /home/dave/nasmjf/nasmjf 37 541 stosw ; and store it in the header. 38 544 mov al, cl ; Get the length. 39 (gdb) x/x &var_HERE 40 0x804a384 <var_HERE>: 0x0000a3bc 41 42 First, the truncation of the address is an easy fix. 43 Just needed to change "stosw" to "stosd". 44 45 (This is one of those cases where the size of a 46 "word" has lost all meaning in x86. It should be 47 the native data size of the CPU, but it got stuck 48 at 16 bits. So 32bit and 64bit x86 has "double" 49 and "big fat juicy sausage" for its native data 50 sizes respectively. Brilliant!) 51 52 541 stosd ; and store it in the header. 53 (gdb) x/x &var_HERE 54 0x804a384 <var_HERE>: 0x0804a3bc 55 56 The funny thing about my mistake with var_HERE 57 is that it's probably let me get further than I 58 should have: it currently doesn't store the 59 correct address at all! So I'll fix the typo 60 first and then add the memory allocation next.