IRC channel logs

<wildwestrom>I was wondering if somebody could tell me about the "knight" ISA. What's it based on? Is it entirely new? Since other ISAs can be used to create hardware, why create knight?

<wildwestrom>If you, Jeremiah, are here, I'd love to hear about it.

<matrix_bridge><Jeremiah Orians> The knight ISA is based on an old symmetric complement architecture that I found more than a decade ago.

<wildwestrom>Hey, thanks for getting back to me! By the way, I didn't know there was a matrix bridge. I thought all the libera.chat ones were shut down.

<matrix_bridge><Jeremiah Orians> They were; stikonas runs his own

<wildwestrom>Jeremiah Orians: So I guess that's why I wasn't able to find any information other than your spec on stage0.

<matrix_bridge><Jeremiah Orians> Yeah, I mostly used it because it forced me to make the early steps independent of operating systems and platform neutral. Which after the cc_* steps, matters less.

<stikonas>and it's also harder to document what compilers (cc_* and M2-Planet) support

<stikonas>early programs are simpler, so easy to write a spec

<wildwestrom>So you're saying knight is a way to simplify creating the early binary/hex-based stages. I guess it's harder to say "we wrote binary targeting this bare-metal ISA and it will always work" for AMD64, ARM, RISC-V, etc.

<matrix_bridge><Jeremiah Orians> Well any binary we make can in a few short years become broken by hardware changes or substrate changes (as has already occurred to us such as when Linux changed how it parsed ELF files)

<stikonas>or BIOS got replaced with UEFI

<stikonas>so builder-hex0 doesn't work there

<stikonas>(except that UEFI is older than builder-hex0 but still)

<matrix_bridge><Jeremiah Orians> Basically keeping a bootstrapping chain alive is going to require work forever and the problem of new language chains will only continue to grow as we try to create paths to older languages that don’t have bootstrapping chains yet.

<stikonas>yeah, new languages is going to be harder than C in the long term

<wildwestrom>Anyway, I'm more interested in eliminating steps within the bootstrap process. I checked out live-bootstrap, and there are over 136 steps to get to GCC 4.7.4.

<stikonas>well, that's to large extent because we try to regenerate automatically generated files

<stikonas>without that bootstrap chain is much shorter

<wildwestrom>I suppose at that point it's a question of, do we want to build on this chain, or go the route of Collapse OS.

<wildwestrom>Thank you to whoever is maintaining the archive by the way. Helped me find if my questions have already been answered or not.

<mihi>wildwestrom: For reference <https://github.com/schierlm/FullSourceBootstrapFromGit> (which mostly follows the Guix bootstrap chain without any Guile/slow-utils stuff) needs about 30 steps to get from M2-Planet to GCC 4.6.4. So when you do not avoid regenerated files, the chain get shorter, but still quite complicated :)

IRC channel logs

2025-08-04.log