I'm quite fond of Spleen:

https://github.com/fcambus/spleen

It has a 5x8 font which has all of ASCII, but most glyphs are actually 4x8 and include horizontal spacing. I modified it to reduce the rest for a project I'm doing so all glyphs are 4x8. The result can be rendered on a 5x9 grid with a guaranteed line of horizontal and vertical spacing between all glyphs. It's very nice.

One of the VMs I wrote for Onramp is in POSIX shell [1]. This was intended to make C bootstrappable on any POSIX system of any architecture with nothing besides the shell. Unfortunately it's about 100,000x too slow to be useful. It's also at least as complicated as a machine code VM. I've since mostly abandoned the POSIX shell idea.

Onramp does have a very simple C89 VM though, and its purpose is for bootstrapping modern C on systems that have only a basic C compiler [2]. So this c89cc.sh could in theory work. I tried it and unfortunately it doesn't quite compile yet (and doesn't give a comprehensible error message either.) Even if it worked, c89cc.sh only compiles to x86_64 ELF, and it's way more complicated than the x86_64 ELF machine code Onramp VM [3].

This has been a bit of a recurring theme with Onramp: anything I've tried to get away from the initial machine code stages ends up being more complicated than handwritten machine code. Still, it's nice to have a lot of different ways to bootstrap. I love seeing projects like this and I'm glad to see more people taking bootstrapping seriously.

[1]: https://github.com/ludocode/onramp/blob/develop/platform/vm/...

[2]: https://github.com/ludocode/onramp/blob/develop/platform/vm/...

[3]: https://github.com/ludocode/onramp/blob/develop/platform/vm/...

I run btrfs on top of mdraid in RAID6 so I can incrementally grow it while still having copy-on-write, checksums, snapshots, etc.

I hope that one day btrfs fixes its parity raid or bcachefs will become stable enough to fully replace mdraid. In the meantime I'll continue using mdraid with a copy-on-write filesystem on top.

https://frame.work/ca/en/products/cooler-master-mainboard-ca...

I put my original mainboard in one of these when I upgraded. It's fantastic. I had it VESA-mounted to the back of a monitor for a while which made a great desktop PC. Now I use it as an HTPC.

In my first stage Onramp linker [1], converting linear search to an open hash table adds a grand total of 24 bytecode instructions, including the FNV-1a hash function. There's no reason to ever linear search a symbol table.

[1]: https://github.com/ludocode/onramp/blob/develop/core/ld/0-gl...

Looks like it makes quite a few changes to C so it can't really run unmodified C code. I wonder how much work it would take to convert a full C compiler into something DuskCC can compile.

One of my goals with Onramp is to compile as much unmodified POSIX-style C code as possible without having to implement a full POSIX system. For example Onramp will never support a real fork() because the VM doesn't have virtual memory, but I do want to implement vfork() and exec().

A modern UEFI is probably a million lines of code so there's a huge firmware trust surface there. One way to eliminate this would be to bootstrap on much simpler hardware. A rosco_m68k [1] is an example, one that has requires no third party firmware at all aside from the non-programmable microcode of the processor. (A Motorola 68010 is thousands of times slower than a modern processor so the bootstrap would take days, but that's fine, I can wait!)

Of course there's still the issue of trusting that the data isn't modified getting into the machine. For example you have to trust the tools you're using to flash EEPROM chips, or if you're using an SD card reader you have to trust its firmware. You also have to trust that your chips are legit, that the Motorola 68010 isn't a modern fake that emulates it while compromising it somehow. If you had the resources you'd probably want to x-ray the whole board at a minimum to make sure the chips are real. As for trusting ROM, I have some crazy ideas on how to get data into the machine in a trustable way, but I'm not quite ready to embarrass myself by saying them out loud yet :)

[1]: https://rosco-m68k.com/

Programming for a stack machine is really hard, whereas programming for a register machine is comparatively easy. I designed the Onramp VM specifically to be easy to program in bytecode, while also being easy to implement in machine code. Onramp bootstraps through the same linker and assembly languages that are used in a traditional C compilation process so there are no detours into any other languages like Forth (or Scheme, which live-bootstrap does with mescc.)

tl;dr I'm not really convinced that Forth would simplify things, but I'd love to be proven wrong!

[1]: https://github.com/oriansj/stage0?tab=readme-ov-file#forth

Comments URL: https://news.ycombinator.com/item?id=42547086

Points: 79

# Comments: 24

I did 2023 Advent of Code with my own compiler and this was the biggest challenge I ran into. I only had 32-bit integers at the time so I had to manually implement 64-bit math and number formatting within the language to be able to do the puzzles. You would probably have to do the same in BASIC.

I seem to recall complaints that old rustc would take many hours to compile itself. Even if it takes on average, say, two hours to compile itself, that's well over a week to bootstrap all the way from 0.7 to present. You're right that months is probably an exaggeration, but I suspect it might take a fair bit longer than a week. The truth is probably somewhere in the middle, though I suppose there's no way to know without trying it.

You need some way of getting this hex tool in memory of course. On traditional computers this could be done on front panel switches, but of course modern computers don't have those anymore. You could also imagine it hand-woven into core rope memory for example, which could then be connected directly to the CPU at its boot address. There are many options here; getting the hex tool running is very platform-specific.

Once you have a hex tool, you can then use that to input the next stage, which is written in commented hexadecimal source code. The next tool then adds a few features, and so does the tool after that, and so on, eventually working your way up to assembly and C.

Security is a big reason and it's one the bootstrappable team tend to focus on. In order to avoid the trusting trust problem and other attacks (like the recent xz backdoor), we need to be able to bootstrap everything from pure source code. They go as far as deleting all pre-generated files to ensure that they only rely on things that are hand-written and auditable. So bootstrapping Python for example is pretty complicated because the source contains code generated by Python scripts.

I'm much more interested in the cultural preservation aspect of it. We want to preserve contemporary media for future archaeologists, for example in the Arctic World Archive [1]. Unfortunately it's pointless if they have no way to decode it. So what do we do? We can preserve the specs, but we can't really expect them to implement x265 and everything else they would need from scratch. We can preserve binaries, but then they'd need to either get thousand-year-old hardware running or virtualize a thousand-year-old CPU. We can give them, say, a definition of a simple Lisp, and then give them code that runs on that, but then who's going to implement x265 in a basic Lisp? None of this is really practical.

That's why in my project I made a simple virtual machine, then bootstrapped C on top of it. It's trivially portable, not just to present-day architectures but to future and alien architectures as well. Any future archaeologist or alien civilization could implement the VM in a day, then run the C bootstrap on it, then compile ffmpeg or whatever and decode our media. There are no black boxes here: it's all debuggable, auditable, open, handwritten source code.

[0]: https://github.com/ludocode/onramp?tab=readme-ov-file#why-bo...

[1]: https://en.wikipedia.org/wiki/Arctic_World_Archive

Moreover, I believe the earlier versions of rustc only output LLVM, so you need to bootstrap a C++ compiler to compile LLVM anyway. If you have a C++ compiler, you might as well compile mrustc. Currently, mrustc only supports rustc 1.54, so you'd still have to compile through some 35 versions of it.

None of this is practical. The goal of Dozer (this project) is to be able to bootstrap a small C compiler, compile Dozer, and use it to directly compile the latest rustc. This gives you Rust right away without having to bootstrap C++ or anything else in between.

These are all genuine attack vectors but they are not really solvable from the software side. At least for Onramp I consider these problems to be out of scope. It may be possible to solve these with open hardware but a solution will look very different from the kind of software bootstrapping we're doing.

I've spent a lot of my spare time the past year or so working on my own attempt at a portable bootstrappable compiler. It's partly to prevent this attack, and also partly so that future archaeologists can easily bootstrap C even if their computer architectures can't run any binaries from the present day.

https://github.com/ludocode/onramp

It's nowhere near done but I'm starting a new job soon so I felt like I needed to publish what I have. It does at least bootstrap from handwritten x86_64 machine code up to a compiler for most of C89, and I'm working on the final stage that will hopefully be able to compile TinyCC and other similar C compilers soon.

Of course it is. If you add AdSense to your website you are letting Google track your users in exchange for a cut of the profits. Of course you should have to warn your users that they are being tracked at the very least.

- TinyCC, SCC (Simple C Compiler) and Kefir are all fairly serious projects in active development.

- QBE is a new optimizing backend much simpler than LLVM; cproc and cparser are two of the C compilers that target it, in addition to its own minic.

- There's the bootstrapping work of stage0, M2-Planet, and mescc.

- chibicc is an educational C compiler based on the author's earlier 8cc compiler. The author is writing a book about it.

- lacc is another simple compiler that works well, although development appears to have stalled.

I think a lot of these projects are inspired by the problem that GCC and Clang/LLVM are now gigantic C++ projects. A pure C system like OpenBSD or Linux/musl/BusyBox ought to be able to compile itself without relying on C++. We really need a production quality open source C compiler that is actually written in C. I'm hopeful one of these compilers can achieve that someday.