{"id":544,"date":"2024-05-26T23:18:44","date_gmt":"2024-05-27T04:18:44","guid":{"rendered":"https:\/\/greg-kennedy.com\/wordpress\/?p=544"},"modified":"2024-05-27T00:25:52","modified_gmt":"2024-05-27T05:25:52","slug":"static-recompilation-of-chip-8-programs","status":"publish","type":"post","link":"https:\/\/greg-kennedy.com\/wordpress\/2024\/05\/26\/static-recompilation-of-chip-8-programs\/","title":{"rendered":"Static Recompilation of CHIP-8 Programs"},"content":{"rendered":"\n
\"\"<\/a>
Screenshot of “UFO.ch8” running natively in a terminal<\/figcaption><\/figure>\n\n\n\n

“Static Recompliation<\/a>” is the process of turning a binary program built for one instruction set and CPU into equivalent native code for a different architecture. It’s a hot topic lately as news of a static recompilation process for N64 games – turning the original MIPS code into x86 executables for Windows – seemingly promises an entirely new level of features and performance beyond existing emulation techniques. I’ve been interested in the topic since hearing of the StarCraft on ARM recompilation<\/a> for OpenPandora in 2014, but not looked too much further into the idea until recently. I decided to try my own hand at a static recompiler, where I would be transforming some machine ROM into C source code, then compile that to produce native executables.<\/p>\n\n\n\n

First, I’d need a source system to use: The CHIP-8<\/a> VM, often considered a good “baby’s first emulator” project. It is an interpreted 8-bit machine, with only 30 opcodes or so, limited graphics and sound capabilities and a lot of tooling available. I began by spending a couple of days implementing the machine in C as a plain “interpreted” emulator, using libcurses to handle keyboard input and display visuals on the terminal. This was useful for getting a feel for the machine, learning about quirks and addressing modes, as well as a benchmarking test. Some of the routines for interfacing the VM with the real hardware (e.g. “print screen”, “check keypress” etc) are theoretically reusable in a recompiled version as well. CHIP-8 emulation is a well-studied topic, I won’t say much more about it here.<\/p>\n\n\n\n

With that complete, I turned my attention to the recompilation. If you’d like to see the code I wrote, I’ve placed it in GitHub here:<\/p>\n\n\n\n

https:\/\/github.com\/greg-kennedy\/CURSE-8<\/a><\/p>\n\n\n\n

Inside are the interpreter, and a Perl script “recompile.pl” which turns a .ch8 file into a .c. Compiling this along with “wrapper.c” and linking to libcurses should give a runnable executable of the chip8 program.<\/p>\n\n\n\n

Details of approaches to static recompilation follow.<\/p>\n\n\n\n\n\n\n\n

Basic Plan<\/h1>\n\n\n\n

A first approach to do this is something like so – a portion of the common “IBM Logo” program.<\/p>\n\n\n\n

#include <stdint.h>\n\nuint8_t RAM[4096] = { 0xF0, 0x90, 0x90, 0x90, 0xF0, \/\/ the starting font\n                      0x20, 0x60, 0x20, 0x20, ...,\n                      0x00, 0x00, 0x00, 0x00, 0x00, \/\/ padding to 0x200\n                      0x00, 0x00, 0x00, 0x00, ...,\n                      0x00, 0xe0, 0xa2, 0x2a, 0x60, \/\/ the contents of the ROM\n                      0x0c, 0x61, 0x08, 0xd0, ...\n                    };\n\nvoid main() {\n  \/\/ machine variables\n  uint16_t I;\n  uint8_t v[0x10];\n  uint8_t timer_delay = 0, timer_sound = 0;\n\nlbl_200:            \/\/ decoded instruction at 0x200\n    screen_clear();\nlbl_202:\n    I = RAM[0x22a];\nlbl_204:\n    v[0x0] = 0x0c;\n\/\/ remainder of disassembly\n...\nlbl_280:\n    screen_clear();\nlbl_282:\n    screen_clear();\n\n\/\/ alternate alignment decoding\nlbl_201:\n    return;  \/\/ ILLEGAL OPCODE\nlbl_203:\n    \/\/ CALL lbl_a60;\n...\n}<\/code><\/pre>\n\n\n\n
This copies the ROM into a block at the start of the program, then literally translates each opcode from 0x200 onwards into C code.  It’s done twice, because CHIP-8 has no alignment restrictions but all opcodes are 2 bytes – and so the instructions after a JMP could be at odd-numbered locations instead.<\/p>\n\n\n\n
Much of this is pretty straightforward, but there are two issues relating to control flow that deserve special mention:<\/p>\n\n\n\n