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