Dave's nasmjf Dev Log 25

Created: 2022-07-22

nasmjf home

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.

← Previous 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
    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
← Previous 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25