Nikita Lisitsa

@lisyarus.bsky.social

He/him I teach C++ & computer graphics and make videogames Working on a medieval village building game: https://youtube.com/playlist?list=PLSGI94QoFYJwGaieAkqw5_qfoupdppxHN&cbrd=1 Check out my cozy road building traffic sim: https://t.ly/FfOwR

Almost finished a huge refactor to support bundling several source files into a single executable blob, carefully merging the respective code, data, and relocation buffers, while potentially allowing for parallel compilation. Important for future modules & executable (AOT-compiled) binaries support.

I really need to add thousands of tests for this compiler, including testing the C FFI and ABI conformance and etc etc, but that's 1) a ton of work and 2) feels like committing to another not-just-for-fun project, and tbh I'm not sure if that's what I actually want rn

Nikita Lisitsa@lisyarus.bsky.social · 3d ago

Ohhhhh god I fixed it! The issue was that when comparing two registers I always compare them as 64-bit, sign/zero extending before that if needed. For unsigned 32-bit values I don't zero-extend as writing to low 32 bits of a register automatically clears the top 32 bits...

Aaand now a better image! 256x256, 8k samples, p=0.25 russian roulette (avg path depth=4), ran for 5m30s in 16 threads on a 3.6GHz i9-9900K, written in my own JIT-compiled programming language that now compiles to both aarch64 and x86_64!

Bild

Ohhhhh god I fixed it! The issue was that when comparing two registers I always compare them as 64-bit, sign/zero extending before that if needed. For unsigned 32-bit values I don't zero-extend as writing to low 32 bits of a register automatically clears the top 32 bits...

Bild

So my raytracer + compiler bug is unbelievably subtle. The image should be all-white but for some reason it isn't. Removing some lines (typically dead code - unused values / uncreachable instructions) removes the bug. I've spent way too many hours in gdb by now...

BildBild

Turned out I messed up the implementation of conditional jumps in my language's x86_64 compiler. Now the raytracer works properly! Meaning it runs in several threads, reports progress, and generates an image. The image is a bit off, though, but that's no big deal 😅

Bild

Toy programming language compiler x86_64 backend status: implemented (almost) everything, the raytracer test program successfully compiles and runs! ...but never finishes and never prints anything and never creates the threads as it's supposed to, not to mention the output file 😅

TIL there's no unsigned 64-bit -> floating-point 64-bit conversion in x86_64, so you have to build it up from other instructions. Here's the codegen by gcc-15.2 with -O3, it uses different code paths based on the highest bit of the input:

Bild

The x86_64 compiler backend for my pet language is about 75% done - what's left are function calls, pointer load/store, struct function arguments, and some clean-up. Keep in mind that it's not even close to an optimizing compiler (yet), so the codegen is rather pathetic

BildBild

Currently the parser doesn't allow newlines before the opening curly brace {, which forces a certain formatting style. Not sure if I want to keep that or allow a different style, though...

BildBild

I decided to ditch indentation-based scoping in favor of explicit curly braces. It's a bit more verbose, but to me it feels more readable. Maybe it's just a habit? Also the parser is 50% simpler now 😅

BildBild

Been toying with the idea of rewriting my engine's debug renderer using SDFs supporting arbitrary affine transformations, and strokes (i.e. drawing the object boundary with some width) turned out to be much harder than I expected 😅

Bild