DOOM Runs (slowly) In A IBM PC-Compatible CSS Sheet

July 15, 2026 by Tyler August 10 Comments

Just when you thought we’d run out of things to port DOOM to, here comes [Ahmed Amer] with his CSS-DOS, a massive 300 MB CSS style sheet, that runs not just DOS, but Windows 1.0 and, of course, DOOM. The CSS sheet isn’t holding a DOOM port this time, though — it’s holding a full IBM PC compatible, with a simulated 8086, 640 kB of RAM, floppy and VGA controllers. Yes, in one style sheet. We did mention it was 300 MB, right?

CSS is not a very good programming language. It’s got functions and if statements nowadays, but it doesn’t really do programs in the usual sense. That is, lists of instructions that feed one into another. You can’t change a variable without jumping through hoops. The sort of static behavior you get from a CSS sheet actually matches hardware architecture better than software, which was the key insight [Ahmed] had to make the project possible. It’s still not easy, or elegant, or perhaps even sane, as you can find out from the excellent write-up he has describing how he pulled this off. We particularly like the interactive guide to the full mountain of madness that is the .css file.

Now, we admit that “runs DOOM” may be an exaggeration — even if the maddeningly massive CSS sheet ran an IBM-AT full speed, that hardware can’t handle the game at any playable speed. It doesn’t emulate at anything close to full speed, though. Because this is such a gratuitously weird hack, it only runs at two instructions per second. No, not FPS, instructions, as in at the CPU level. Well, it could be worse, at least it’s not clock ticks. Still, if you’re time-dilated enough you can wait the 3 weeks to boot DOS, and the 3 months to load a level, you can play DOOM at 0.0001 FPS.

Look, we didn’t make the rules — they say everything has to try and run DOOM. They don’t say everything has to run it well.

How Small Can You Make A C Executable?

June 7, 2026 by Jenny List 46 Comments

It’s well known that the difference in executable size between a compiled binary and one hand-written in optimized assembler will be significant. The compiler brings in all manner of boilerplate whether it needs all of it or not, which is responsible for the extra space. [Weineng] has fallen down the rabbit hole of trying to make the smallest possible gcc-compiled C executable, and the resulting write-up is a fascinating read.

Surprisingly the smallest C program isn’t “Hello World”, but one which simply does nothing but return 0. This results in a binary weighing in at a surprisingly large 15,816 bytes — something which surely could be improved. There follows a set of clever compiler flags and bits of code manipulation to remove some debugging information, and strip out unnecessary stuff executed before void main().

At 13,632 bytes it’s still a little on the chunky side, so it’s time to examine what libraries it brings in. More compiler flags get it down to 8,704 bytes. Removing a code comment section and error handling with more flags takes it to 4,320 bytes. Then there’s code which dictates how memory is allocated, which brings it down to 400 bytes. That’s an impressive reduction!

Reading this as hardware people we maybe don’t have the elite knowledge of compiler flags it takes to manage something like this. But we’ve all at times had to reduce the size of a bit of software, so we’re sure some of the techniques used are going to be interesting to quite a few readers.

After all, even hardware people need to trim the fat at times.

A RISC-V LISP Compiler…Written In Lisp

October 14, 2024 by Dave Rowntree 15 Comments

Ah, Lisp, the archaic language that just keeps on giving. You either love or hate it, but you’ll never stop it. [David Johnson-Davies] is clearly in the love it camp and, to that end, has produced a fair number of tools wedging this language into all kinds of nooks and crannies. The particular nook in question is the RISC-V ISA, with their Lisp-to-RISC-V compiler. This project leads on from their RISC-V assembler by allowing a Lisp function to be compiled directly to assembly and then deployed as callable, provided you stick to the supported language subset, that is!

The fun thing is—you guessed it—it’s written in Lisp. In fact, both projects are pure Lisp and can be run on the uLisp core and deployed onto your microcontroller of choice. Because who wouldn’t want to compile Lisp on a Lisp machine? To add to the fun, [David] created a previous project targeting ARM, so you’ve got even fewer excuses for not being able to access this. If you’ve managed to get your paws on the new Raspberry Pi Pico-2, then you can take your pick and run Lisp on either core type and still compile to native.

The Lisp-Risc-V project can be found in this GitHub repo, with the other tools easy enough to locate.

We see a fair few Lisp projects on these pages. Here’s another bare metal Lisp implementation using AVR. And how many lines of code does it take to implement Lisp anyway? The answer is 42 200 lines of C, to be exact.

Compiling Four Billion If Statements

August 7, 2024 by Matthew Carlson 44 Comments

With modern tools, you have to try very hard to do something stupid, because the tools (rightly) recognize you’re doing something stupid. [Andreas Karlsson] can speak to that first hand as he tried to get four billion if statements to compile.

You may ask what state space requires four billion comparisons to evaluate? The answer is easy: the range of an unsigned 32-bit integer. The whole endeavor started with a simple idea: what if instead of evaluating whether an integer is even or odd with a modulo or bit mask, you just did an if statement for every case? Small ranges like 0-10 are trivial to write out by hand, but you reach for more automated solutions as you pass 8 bits and move towards 16. [Andreas] wrote some Python that outputs a valid C program with all the comparisons. For 16 bits, the source only clocks in at 130k lines with the executable less than 2 MB.

Of course, scaling to 32 bits is a very different problem. The source file balloons to 330 GB, and most compilers barf at that point. Undeterred, [Andreas] modified the Python to output x86_64 assembly instead of C. Of course, the executable format of Windows (PE) only allows executables up to 4 GB, so a helper program mapped the 40 GB generated executable and jumped into it.

What’s incredible about this whole journey is how performant the program is. Even large numbers complete in a few seconds. Considering that it has to thrash 40 GB of an executable through memory, we can’t help but shake our heads at how even terrible solutions can work. We love seeing someone turn a bad idea into an interesting one, like this desoldering setup.

C Compiler Exists Entirely In Vim

July 7, 2024 by Donald Papp 36 Comments

8cc.vim is a C compiler that exists as pure Vimscript. Is it small? It sure is! How about fast? Absolutely not! Efficient? Also no. But does it work and is it neat? You betcha!

Ever typed :wq to write the buffer and exit in Vim? When you do that, you’re using Vimscript. Whenever one enters command mode : in Vim, one is in fact using a live Vimscript interpreter. That’s the space in which this project exists and does its magic. Given enough time, anyway.

Vimscript itself was created by [Bram Moolenaar] in 1991. The idea was to execute batches of vim commands programmatically. It’s been used for a variety of purposes since then.

8cc is a lightweight C compiler that has been supplanted by chibicc, but that doesn’t matter much because as author [rhysd] admits, this is really just a fun concept project more than anything. It may take twenty minutes or more to compile “hello world”, but doing it entirely from within Vim is a trip.

Hackaday Links: May 26, 2024

May 26, 2024 by Dan Maloney 5 Comments

Another day, another crop of newly minted minimal astronauts, as Blue Origin’s New Shepard made a successful suborbital flight this week. Everything seemed to go according to plan, at least until right at the end, when an “unexpected foliage contingency” made astronaut egress a little more complicated than usual. The New Shepard capsule had the bad taste to touch down with a bit of West Texas shrubbery directly aligned with the hatch, making it difficult to find good footing for the platform used by the astronauts for the obligatory “smile and wave” upon exiting. The Blue Origin ground crew, clad in their stylish black and blue outfits that must be murderously impractical in the West Texas desert, stamped down the brush to place the stairway, but had a lot of trouble getting it to sit straight. Even with the impromptu landscaping, the terrain made it tough to get good footing without adding random bits of stuff to prop up one leg, an important task considering that one of the new astronauts was a 90-year-old man. It seems pretty short-sighted not to have adjustable legs on the stairway, but there it is.

Continue reading “Hackaday Links: May 26, 2024” →

Cowgol Development Environment Comes To Z80 And CP/M

December 10, 2023 by Donald Papp 7 Comments

Cowgol on Z80 running CP/M ties together everything needed to provide a Cowgol development environment (including C and assembler) on a Z80 running the CP/M operating system, making it easier to get up and running with a language aimed to be small, bootstrapped, and modern.

Cowgol is an experimental modern language for (very) small systems.

The Zilog Z80 was an 8-bit microprocessor common in embedded systems of the 1970s and 1980s, and CP/M was a contemporary mass-market operating system. As for Cowgol? It’s an Ada-inspired compiler toolchain and programming language aimed at very small systems, such as the Z80.

What’s different about Cowgol is that it is intended to be self-hosted on these small systems; Cowgol is written in itself, and is able to compile itself. Once one has compiled the compiler for a particular target architecture (for example, the Z80) one could then use that compiler on the target system to compile and run programs for itself.

Thankfully, there’s no need to start from scratch. The Cowgol on Z80 running CP/M repository (see the first link of this post) contains the pre-compiled binaries and guidance on using them.

Cowgol is still under development, but it works. It is a modern language well-suited to (very) small systems, and thanks to this project, getting it up and running on a Z80 running CP/M is about as easy as such things can get.

Thanks to [feinfinger] for the tip!