Self-hosting (chibicc-uxn compiling itself)

[lynn]

There are really two steps here:

1. Get the project to a point where chibicc-uxn.exe (running in Windows/Linux/etc) can compile the codebase to cc.rom, and this cc.rom can compile something FizzBuzz-sized.
2. Get the project to a point where even this cc.rom (running in Uxn) can compile the whole codebase, and reproduce itself.

The biggest limitation is uxn's limited memory. Right now, chibicc-uxn allocates more than 64kB of memory to compile any non-trivial program. So the former sounds difficult enough, and the latter feels a bit like a pipe dream.

Here's the work that needs to be done:

• Implement more standard library functions, like calloc and strtol and sprintf. A few of these are in lib/ already.
• Remove stuff we don't support from the chibicc source code (like long).
• Right now we rely on an external preprocessor. But such a thing doesn't exist in Uxn-land, so it's probably a bit more meaningful if we at least implement #include and #define. It could be a separate program.
• Severely reduce the memory usage somehow, or find a clever way to manage memory.

[hikari-no-yume]

One thing I'd like to explore is splitting up chibicc's different phases, which are conveniently separate already, into separate programs. So tokenisation, parsing, codegen and optimisation could potentially be separate executables. That might help a bit with memory use?

[retrac0]

One thing I'd like to explore is splitting up chibicc's different phases, which are conveniently separate already, into separate programs. So tokenisation, parsing, codegen and optimisation could potentially be separate executables. That might help a bit with memory use?

Probably. It was a common practice historically to fit large compilers into small systems.

If still memory-constrained, the largest data structures could be moved to files rather than kept in memory. But that has an awful complexity + speed penalty.