IRC channel logs

<siraben>working on redoing it all in a Mini OCaml instead

<siraben>Could be considerably faster while still being readable, if the dialect has enough features

<xentrac>that sounds very promising

<siraben>Also, the github aarch64 runners are slower than using qemu on amd64 on github runners lol

<siraben>was wondering why my full pipeline CI was taking like 30min

<xentrac>maybe Microsoft needs to buy some Mac M4s

<siraben>ever since apple switched to ARM for their M series it's been nothing short of amazing, tbh. I was about to switch to a Linux based laptop after my 2014 MacBook Pro died (and lasted like 7 years)

<siraben>and how you can run Asahi Linux up to M2 I think

<siraben>ACTION is also working on a from-source bootstrap on darwin

<roconnor_>redoing hcc in mini ocaml?

<roconnor>xentrac: looks like a carefully crafted RV32E binary will run on any RiscV machine.

<xentrac>I like OCaml and Scheme both, but I feel like OCaml is more practical in a lot of ways

<xentrac>roconnor: plausibly, although RV64 has enough mismatches with RV32 to make it tricky

<xentrac>and assuming you can somehow load the binary into its memory and start it executing

<roconnor>Yeah, the ELF header needs to be changed, but that's about it.

<roconnor>All thanks to the magic that is auipc

<siraben>roconnor: possibly. i'm scoping it out

<siraben>something like the Zinc vm would be good

<matrix_bridge><Jeremiah Orians> Roconnor: honestly, the only really annoying thing about RISC-V is their immediate encoding but honestly it wasn’t too bad once we realized that their documentation was incorrect too. (And yeah it took a bit before we hammered out the last of those bugs) but it permanently changed mescc-tools for the better. AArch64 would be so much cleaner if anyone redid it now

<xentrac>the vast majority of RISC-V machines don't run any operating systems that could conceivably care about the ELF header

<xentrac>oriansj: what wast he general shape of the changes to mescc-tools? also nice to see you again

<matrix_bridge><Jeremiah Orians> It moved from being byte oriented to also supporting word oriented syntax that maps much better for most architectures.

<xentrac>aha! yeah, that makes a lot of sense

<matrix_bridge><Jeremiah Orians> And always good to see you around

<xentrac><3

<xentrac>starting with amd64 you'd naturally start with byte-oriented

<roconnor>xentrac: That's true, but I'm starting with posix-riscv since it is easier. But hopefully the assembly will be easy to port.

<matrix_bridge><Jeremiah Orians> Started with Knight honestly and x86/AMD64 ported pretty easily

<xentrac>roconnor: what do you mean?

<xentrac>oriansj: oh, right, I forgot Knight's instruction set encoding was also byte-oriented

<xentrac>there were a lot of word-oriented instruction encodings in the 60s and 70s but mostly on computers whose memory wasn't byte-oriented, like the CDC 6600 and the PDP-8

<roconnor>xentrac: I'm writing my vm in linux-riscv user space assembly, with ecalls and whatnot, however you say that

<xentrac>roconnor: oh, you mean with respect to crafting RV32E code to run on any RISC-V machine? yeah, starting on Linux is probably the right approach

<roconnor>Any RiscV posix machine (- -;)

<xentrac>yes, but that's a vanishingly small fraction of RISC-V machines

<xentrac>maybe one in ten thousand or one in a hundred thousand

<roconnor>Porting builder-hex0 to RiscV is probably a thing that is possible.

<matrix_bridge><Jeremiah Orians> Oh definitely if someone is willing to put in the work

<matrix_bridge><Andrius Štikonas> roconnor: also all the function headers booters are different between rv32 and rv64

<matrix_bridge><Andrius Štikonas> you would have to actively avoid that in your crafting

<roconnor>Yeah. I think that is the only incompatability.

<stikonas>roconnor: as for builder-hex0, riscv doesn't have standard BIOS, so you'll need to port that builder-hex0 to each board

<stikonas>as I/O might be different

<roconnor>yikes

<stikonas>well, you could use middle ground

<stikonas>e.g. assume u-boot and uefi api

<matrix_bridge><Andrius Štikonas> but that's not exactly baremetal

<xentrac>I/O being different is not that big a deal usually

<stikonas>xentrac: normally maybe not but in hex it's a bit more complicated

<stikonas>you need to plan it carefully

<stikonas>perhaps put at the very end of the program

<stikonas>otherwise all jumps and labels change and they are very painful to deal with in riscv hex

<stikonas>far worse than in x86

<xentrac>stikonas: oh, that's a good point

<stikonas>somebody also tried to implemnt arch independent chain from M0: https://git.ryansepassi.com/boot2/files.html

<matrix_bridge><Jeremiah Orians> Or one could steal an old BIOS trick and just make a jump table that you can index to get the desired target with a single place where the changed address would need to be

IRC channel logs

2026-05-18.log