IRC channel logs

<oriansj>well there certainly are a good few build your own CPUs and computers with bootstrap potential

<oriansj>but they either are 8bit (or smaller) or span a half dozen boards or end up using microcode

<muurkha>oriansj: all of those are reasonable options

<muurkha>even if it would be nicer to have a CPU that didn't have those disadvantages, yet was still auditable

<oriansj>well those using microcde would be the cheapest and could have an implementation spanning multiple boards (ah la IBM 360) but I don't know of an option which satisfies that

<muurkha>satisfies what?

<oriansj>a single consistent architecture available as a lean microcode design and a microcode free design.

<oriansj>RISC-V has potential but none of the designs seem to cover the exact same ISA options; unless we just assumed only the core instructions.

<muurkha>RV32I is more than adequate for self-hosting

<oriansj>well no

<oriansj>one either needs syscall support or some standard (like bios) for dealing with I/O

<muurkha>you can invoke subroutines for dealing with I/O; that's what RTOSes do

<muurkha>syscall support is for privilege separation and fault isolation

<muurkha>but you can totally just call into a VDSO for your I/O

<oriansj>muurkha: well those subroutines would need to be in ROM with a standard routine table; otherwise we would need to customize the early steps to each and every different implementation. Unless we hard code an I/O memory map of sorts

<muurkha>yeah, you could use standard addresses, or a single standard address with a register that selects which routine to call, or a standard address with a symbol table, or whatever

<vagrantc>ACTION hopes the sunshine lasts long enough to build mes on riscv64 today :)

<oriansj>vagrantc: going solarpunk?

<oriansj>muurkha: well RISC-V systems are starting to adopt the UEFI standard but that is far from a minimal bootstrap for hardware

<vagrantc>oriansj: heh. kindasorta

<stikonas>well, u-boot implements enough UEFI for bootstrapping...

<stikonas>you don't even need something as big as EDK2

<oriansj>vagrantc: nice.

<oriansj>stikonas: I only need a BIOS with read block, write block, read key and a memory address where I can do VGA style output.

<oriansj>everything else we can device tree in Linux after the bootstrap

<vagrantc>my little riscv64 board is a meek little solar powered space heater that happens to also be able to compile code :)

<stikonas>which board do you have?

<vagrantc>unmatched

<vagrantc>not the fastest processor, but 16gb of ram and an nvme disk partly make up for that :)

<stikonas>well, but mes will be slow...

<stikonas>it takes days on my visionfive2

<vagrantc>yes, it manages to use approximately exactly 25% of the available CPU (e.g. 1 core at full steam)

<stikonas>though tcc and especially gcc are faster

<vagrantc>i wish suspend worked on it ... then i could suspend at night, resume the next day :)

<vagrantc>having some sort of progress indicator with mess would be nice

<vagrantc>got as far as: + /<<PKGBUILDDIR>>/bin/mes --no-auto-compile -e main -L /usr/share/guile/site/3.0 -C /usr/lib/guile/3.0/site-ccache /<<PKGBUILDDIR>>/scripts/mescc.scm -- -m 64 -c -D HAVE_CONFIG_H=1 -I ../lib -I ../include -I ../include -I include -v -static -nostdinc -nostdlib -fno-builtin -o lib-stdlib-puts.o ../lib/stdlib/puts.c

<stikonas>ok, so it's doing something then

<stikonas>still, that's much faster then building tcc

<stikonas>that one is without any progress at all

<vagrantc>ouch

<stikonas>well, over a few days it prints a few warnings in the middle

<stikonas>and for 1 day or so at the end I can watch the size of output file (tcc.s)

IRC channel logs

2023-11-23.log