Assembly Nights

For reasons I can’t explain, it just feels right to use my tiny computer with its tiny keyboard to type tiny instructions late at night. I suppose it stands to reason that being in a completely different environment from my normal desktop development machines put me in a receptive learning mood.

Also, though I did install Lynx (wikipedia.org), this is not a great machine for modern Web surfing (except for ratfactor.com, of course). So it’s a pretty distraction-free device.

Since this little computer is used for nothing else, I’ve been slowly customizing it for this one task: when I log in, my .bash_profile script immediately does a cd to my assembly project directory.

I have a bunch of little cryptic one and two-letter scripts and aliases that open my project and related documentation in Vim, or start up the GDB debugger and run a GDB script with a breakpoint at the last thing I was working on.

These little things make it so much easier to get going when I’m tired and not feeling like expending much effort. Now I’m at the point where grabbing the eeePC, logging in, and opening the assembly project is automatic, like brushing my teeth.

So, what’s this project I’m working on?

Immediately after completing the lessons on asmtutor.com (see NASM under Resources below), I immediately began on one of the "bucket list" projects I’d shelved many moons ago: reading and understanding Richard WM Jones’s JONESFORTH.

There are a couple mirrors of the JonesForth source on Github. Here’s the copy I grabbed: https://github.com/nornagon/jonesforth

But not content to merely read it, I’ve decided to port it to NASM.

The progress has been incredibly slow because I’m new to assembly in general and NASM specifically. JonesForth is written in GAS (the GNU Assembler) with a completely different syntax. Even the machine instruction mnemonics are different because GAS often includes the size of the data being manipulated as part of the mnemonic.

(Check out Why no one should use the AT&T syntax ever, for any reason, under any circumstances for a more thorough rant than I could hope to write about the syntax.)

The biggest initial challenge was porting some vital macros from GAS to NASM. Each one took weeks to understand and convert.

But it’s pretty awesome and satisfying to be working on something non-trivial, even if it started way over my head. I’ve wanted to give up on this so many times, but I just keep grinding away at it and the barriers are slowly giving way. Every time I figure out what a new instruction does or fix a bug, it’s a little triumph.

Okay, here’s the repo with my progress:

https://github.com/ratfactor/nasmjf

In particular, check out the log files (log01.txt, log02.txt, etc.). They document my trials and tribulations. I wish I’d been doing them from the start but I’m glad I’m doing them now.

This section is an update:

I "accidentally" put a deadline on the JonesForth port recently. I want to finish off a bunch of the little projects I’ve accrued for myself this year so I can more single-mindedly focus on a few bigger ones going into the next year. Well, as soon as I had that deadline, you know what happened? I started trying to hurry through blocks of JonesForth assembly, converting them to NASM as fast as I could. Stupid, right?

I knew I had to force myself slow down. But that’s easier said than done. A sense of urgency is easily gained, but not so easily lost.

My "shower epiphany" last night (this is days after writing this original article), was how to go about slowing down. And here it is: I’m going to stop where I’m at in the translation, fix any syntax errors so the thing assembles, and then walk through every single instruction I’ve got so far and make sure it all works as expected. And to make that more enjoyable and actually have something to show for my efforts when I’m done, I’m going to log the whole session. I don’t even have X on this computer, so the obvious choice for logging is GNU Screen, the terminal multiplexer.

My first thought was, oh great, now I have to learn another tool and get completely sidetracked!

Then my second thought was, hold on, that is great. Now I can finally learn another big ubiquitous GNU application properly and have another tool I’m confident using. Plus, I think Screen will be useful for all kinds of convenience improvements: I’m currently using Linux’s virtual terminals (Alt-F1, Alt-F2, etc.) to have a Vim session and GDB session both open for easy reference. I have to manage those manually. With Screen, I’m pretty sure I can automate opening both things with a single command and then be able to toggle between them with Screen’s Ctrl-a, Ctrl-a.

So I’m currently reading the entire GNU Screen User’s Manual and trying it all out so I know what my options are. Then I’m going to log a big old GDB session and turn it into a transcript which can go into the repo as another artifact on the journey. Now I’m imagining a series of brief session transcripts in which I explore each new bit of functionality. I think this will be really neat.

(Update: I’m doing this! Check out the log files in the repo as mentioned above.)

The point is, I sort of lost my way for a moment, thinking of the finished Forth port as the "point" of this exercise. It’s not. The learning process and the skills I acquire are the point. Plus, after the port is done, Assembly Nights are going to turn into Forth Nights. I’ve got Leo Brodie’s Starting Forth and Thinking Forth on my nightstand. So this journey will take however long it takes and it will be glorious.

I like projects. Probably a little too much. Most of my projects are doomed to failure. All of them seem like success at first. Often I don’t realize a project is going to be a failure until I’ve invested quite a bit of time in it because the flaw was in the big picture and I was concentrating on the fun details.

Most of my projects burn bright and then flare out. This is okay! But if it happens too much, it can start to get depressing.

But What I’ve come to realize is that there actually are some projects that are guaranteed success by simply working on them. And as chance would have it, I have two projects like that right now:

Both of these have a clear direction already laid out and any day I work on them, I’m guaranteed to have made forward progress. I’m not used to this and I’m loving it. The rewards are slooooow, but the only way to fail is to stop doing it.

Comfy!