IRC channel logs
2021-07-15.log
back to list of logs
<stikonas>ROM cpu sounds cool but probably not too practical <oriansj>clemens3: There was always hope. in fact I'd argue we are getting better and better at bootstrapping. With more options and more success. Nice video by the way. <oriansj>stikonas: well we know RISC-V can be done on mescc-tools (so logically it'll work just fine in M2-Planet); the only issue is the encoding will be inefficient (like AArch64) but will work if a b it slow. <oriansj>Also MesCC is gaining RISC-V support so that'll be nice <stikonas>well, mescc might not fit on Pineapple One <oriansj>stikonas: yeah, M2-Planet would require tweaks to fit in 512KB of RAM when compiling itself. (It is kinda wasteful) <oriansj>the logical side effect of storing not only the entire input file(s) in memory but also the tokenization information and the emit info to make debugging and porting to new architectures easier. <stikonas>well, maybe Pineapple one will also be upgraded with a bit more RAM <oriansj>well the tweaks needed to cut ram usage wouldn't be hard to do. Convert tokenization from a do all at once to a pull model. Then turn off te M2libc input/output buffering (which will really hurt speed) <oriansj>Especially on flash media (where single byte writes are really expensive) <oriansj>Going from M2-Planet to M2-Planet+M2libc speeds up that case from 14Minutes to 1 second. <pabs3>oriansj: hmm, I'm semi-unsure about even that. an eventual situation might be a bootstrap started by a human reading the .hex0 text+machine-code files printed out on paper as well as their printed machine-code manual and writing out the corresponding bytes to the bootstrap medium themselves somehow. for automated bootstrap testing there is the sed/xxd command you can use just before writing the binaries to the bootstrap medium <oriansj>pabs3: completely fair. A toggle board is definitely a valid option and eliminates the need for one to trust the binaries in bootstrap-seeds. Hence the "NEVER TRUST ANYTHING IN HERE" warning and the hex0 sources for hex0 and kaem-minimal in stage0-posix <pabs3>btw, what is the expected mechanism for writing these binaries to the bootstrap medium? I guess thats easy for virtual machines, just point qemu at your boot binaries <oriansj>pabs3: well I'm planning on using paper tape as my initial bootstrap medium. So standard hole punch will probably work. Floppy disks could be written to with a magnetic needle and a steady hand if one doesn't need much storage capacity. <fossy>i have been trying to figure out for 2 days why the kernel will not recognise the disk <stikonas[m]>Hmm, I'm slightly worried about disk selection on non qemu systems... <oriansj>fossy: well these sorts of things are expected to happen. There are a great many gotchas buried is old code bases. We are lucky to avoid most of them until ooops complete and utter frustration until we figure it out. <oriansj>stikonas: we may wish to incorporate some form of user selection for things that might be different; so that we don't have to cover every edge case. <stikonas>yeah, we might need something like that. Basically, I'm worried about user trying bootstrap form USB stick to test things and accidentally wiping rootfs