Jim Ingram's personal website. Mostly about programming.
Sometimes I like to disassemble ROM dumps for old NES games to figure out how they work. It’s sort of like putting together a puzzle without knowing what the picture will look like beforehand. You start disassembling opcodes at a known entry point (the NES’s 6502-based CPU will jump to the address stored at $FFFC-$FFFD in the ROM cartridge when the machine resets) and follow the control flow through the rest of the ROM. The puzzle isn’t the disassembly itself, which is a purely mechanical process. It’s figuring out what the assembly code is doing, and why it’s doing it. And along the way you can sometimes find interesting bits of code that are unlike what a modern programmer would (or could) write in a high level language. I found one such bit of code in the initialization routines for Excitebike.
You can specify a precision with printf’s
%s conversion to limit how
many characters are printed:
const char *greeting = "Hello, World!\n"; printf("%.5s\n", greeting); // prints "Hello\n"
But what if you don’t know until runtime how many characters you need?
I just started following along with Bob Nystrom’s Crafting Interpreters book a few days ago, and one of the first things I did was set up a Gradle project for the jlox interpreter. It’s a simple Java application with no external dependencies, so the build script is hardly interesting, except for one thing: starting in Chapter 5, there is a GenerateAst “script” needs to be run before compiling, because it generates source files. Turns out, it’s pretty easy to add a code generation task to a Gradle build.
I’ve been a member of SDF Public Access UNIX System for around fifteen years, at the ARPA level for most of that time. They provide a great service, and have hosted various incarnations of my homepage since I first signed up. The most recent was started in November of 2014 as a blog about programming, built with Jekyll and only lasting for a couple of posts (which I have copied over to this site). Then life got busier, and my blog fell by the wayside.
No, not the same two macros as MinUnit. These macros have a few more features, and thus require a bit more from the runtime. Together, the two macros are used to define test functions that run code in a new process, and that have consistent return values to indicate whether the test succeeded, failed, or had an error. All of the code in this post is available on GitHub, under the terms of the MIT License. What follows is a description of the code and how it works.