It is satisfying to watch the test count creep steadily upward. I like to leave off just after writing a failing test, to give me a clear "next task" when I resume work.

#DesmetC #retrocomputing

#DesmetC mul/div/mod i8 bugs seem more or less vanquished, now moving on to i8 comparison, which I probably should have done first, as it's also turning out to be broken.... -1 > 1, don't you know?

Heh, well, can't imagine why the assembler doesn't like that instruction.

Oh gosh

 MOV CL,BYTE [BP-2]
 XCHG CX,AX
 CBW
 XCHG CX,AX
 XCHG CX,AX
 CBW
 XCHG CX,AX
 IMUL CX

When CL absolutely, positively, needs to be sign extended before multiplication

#DesmetC (signed char -> long) promotion is now working on my branch: got it on the first try, which hopefully means I'm internalizing the codebase. Now I will start on tests for mixed-sign arithmetic.

#retrocomputing

Okay, #DesmetC sign-extension in (signed char -> int) promotion now works in my branch. (signed char -> long) does not work yet; it neglects to sign-extend, acting more-or-less like (unsigned char -> long). That's next to fix.

Thankfully, the codebase is small enough that it's not too hard to find the logic responsible for any given codegen decision.

Also, I came up with the trick of having the assembler backend emit comments into the output asm file. This lets me do something like printf debugging to check which codegen cases are being hit and annotate the assembly they're generating.

Naturally this is all test-driven: I'm accumulating regression tests for the broken codegen I've been fixing, and usually the way I find codegen bugs is by writing new tests expecting the mathematically correct answer, and watching them immediately fail.

#retrocomputing

The #DeSmetC compiler codebase is the hairiest code I've had the experience of hacking. K&R style, many global variables, short cryptic names, spooky action at a distance, the shotgun-surgery pattern for type handling splatted around everywhere, oh baby.

For all that, I managed to fix the codegen bug from the Github issues on the ~second day of working on the compiler... that's the beauty of a small codebase.

My fork is here: https://gitlab.cs.washington.edu/fidelp/open_desmet_c
1 bug down, 999 to go...

#retrocomputing

I should post about the latest #retrocomputing project I started.

Problem: I'd like an open-source, self-hosting C compiler on 8086, that supports the large memory model, overlays, and enough C89 to build Lua.

This seems to not exist! K&R is much more common in this size category. Around the time of C89, many compilers bloated to the point of requiring a 386 or better host, though they could still target 8086. The 8086 holdouts were, in general, commercial products that never got a source release.

One notable exception was DeSmet C http://www.desmet-c.com. It seems to have started life as a commercial PC fork of Bell Labs PCC, a small and sturdy K&R compiler. DeSmet 3.1 added "draft ANSI C" support, but this is incomplete, and riddled with code-gen bugs. This version later found itself on Github as OpenDC https://github.com/the-grue/OpenDC.

Aside from all the bugs, this is a pretty cool package: its dis/assembler, debugger, text editor, and some other utilities were also open sourced, and it runs on an 8088 with 256K RAM and two 360K floppies.

The OpenDC person did a good job packaging things up into an easily buildable form, and fixing syntax errors that probably came from running the sources through a different compiler version than expected, so... yes, it does indeed build and self-host... and I've done this on my Book 8088.

So now I will try to fix the bugs and add the missing C89 features. There are many, many of both... gulp.