Dave's nasmjf Dev Log 25
Created: 2022-07-22
This is an entry in my developer’s log series written between December 2021 and August 2022 (started project in September). I wrote these as I completed my port of the JONESFORTH assembly language Forth interpreter.
Okay, I guess I lied. I'm back sooner than I thought. In addition to cleaning up, I've made a much-needed improvement. I now load _all_ of jonesforth.f upon start, so there's no need for the line limit. So I'm properly checking for EOF while reading that file and closing it. It takes a lot of lines of assembly to produce a nice error message. See the label ".loadjf_open_fail" in nasmjf.asm for the listing. (It's not complicated, just long.) Here's how it looks: $ nasmjf/nasmjf ERROR Could not open 'jonesforth/jonesforth.f'. But it still runs fine from the nasmjf/ dir: $ cd nasmjf $ ./nasmjf JONESFORTH VERSION 48 20643 CELLS REMAINING OK And I really love being able to run the test suite to make sure I haven't messed anything up! $ ./test.sh Testing: jonesforth/test_assembler.f Testing: jonesforth/test_comparison.f Testing: jonesforth/test_exception.f Testing: jonesforth/test_number.f Testing: jonesforth/test_read_file.f Testing: jonesforth/test_stack.f Testing: jonesforth/test_stack_trace.f In theory, my Forth source reading mechanism could be used _within_ Forth to load source files on the fly. I think I'll leave that as an "exercise for the reader" as they say. :-) I've started inserting comments in the source to explain how stuff works. I don't want to duplicate Jones's explanations too much. It's helpful to refresh my own understanding. I've understood each part separately, but it's easy to lose the forest for the trees because the way Forth works is so gosh darned clever. Like, painfully clever. I also finally tried something I've wanted to try for a while: using one of NASM's excellent macro features to perform a string length count so I can get rid of the hard-coded name lengths. It turned out to be super easy: %strlen namelen %1 I've converted a couple macros. DEFCODE and DEFWORD are the big ones. I'll do them next. I think I would also like to swap the order of the label and flag parameters on these macros to make them prettier to look at... Two nights later: done! That was a royal pain, but between sed on the command line piping to intermediate files and then some simpler find/replace in Vim, I managed to automate 99% of it. And another night: added way more comments. I'm glad I didn't put too much work into them when i first started because I undertand it so much better now. Also renamed 'r' script to 'build.sh' to make it clearer what it is. Also added a test option to the script for a total of four ways to play: # Usage: # # build.sh Assemble, link # build.sh gdb Assemble, link, and debug # build.sh test Assemble, link, and test # build.sh run Assemble, link, and run Always good to keep honing the dev environment to keep fast iterations as painless as possible. Later: more comments in. Making steady progress. Now trying to figure out if I should arrange the word definitions in an attempt to explain them, or just put all the code words at the front and all the regular words at the end? Several more nights later: Done! It may not be perfect and perhaps I'll come back with more explanations and check over all of my comments again. But I'm calling this thing complete for now. I hope it was fun following along. Happy hacking! -Dave