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 
The mul-div codegen path in #DesmetC is sorta a nightmare because so much is reused between multiplication, division, and mod, and because there are some dodgy special-cases in here from 1990 that demonstrably do the wrong thing. Proceeding slowly with machete and torch, laying down test cases as I go.
#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.
It's been a pretty productive night in the ol' #DesmetC codebase. Regression tests finally checked in, all the mixed-size integer addition/subtraction involving signed chars I could think of is exercised and passing, nice.
Then I try i8 * i8 -> int and it instantly breaks, not so nice 🫠.
Oh well, that gives me something to fix tomorrow.
Also, I haven't ventured into floating point conversion land yet, either. I'm sure that'll have plenty of dragons when used with signed char.
All this is making me appreciate the wisdom of BCPL and B who have just a word-sized type -- or #Forth which takes that and adds char, as a treat.
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.
#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.
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.
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...
Ooh, the-grue, the current maintainer of OpenDC #DesmetC, took my code-gen patch, how awesome! Usually when I pick up an old codebase like this, the maintainer is long gone.
So @linear if you end up wanting to submit patches, that's the place: https://github.com/the-grue/OpenDC
My fork will remain just an unofficial fork.
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.
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...
