IRC channel logs

<xentrac>roconnor: most RISC-V chips are pretty wimpy

<roconnor>stikonas: where does the output end up after two weeks?

<stikonas>roconnor: well, on my disk (nvme)

<stikonas>it's so slow due to mes being memory heavy

<stikonas>and visionfive2 has a very slow ram

<stikonas>once you reach tcc, things are more or less normal speed

<roconnor>still, that's amazing.

<roconnor>I'm not familiar with the RISCV space. Are there bios/firmware issues with this board or is bootstrapping a solved problem?

<xentrac>RISC-V is like ARM in the sense that there isn't really a BIOS/firmware interface standard to speak of

<roconnor>cause it seems that if you can format a NVME drive then no one has hidden software in your compiler and you have checksums.

<roconnor>That's what I was imagining. Seems you could bootstrap x86 seabios or whatever by building a toolchain on RiscV ... but maybe the cross compiling for that isn't available yet.

<roconnor>Also such a process would be less than ideal.

<roconnor>wow those boards are so cheap.

<matrix_bridge><Andrius Štikonas> well, for risc-v we just worked on userspace bootstrap, so it assumes Linux kernel

<stikonas>early bootstrap doesn't need much though

<stikonas>basiscally input/output

<roconnor> https://github.com/oriansj/mescc-tools/blob/master/M1-macro.c#L618

<roconnor>should be checking s rather than ch.

<siraben>m2-planet miscompiles m[a++]

<stikonas>siraben: could very well be. Like I said those fancy new features in M2-Planet (++ being one of them) often work on their own but not in combination

<stikonas>roconnor: yes, should be checking for s

<stikonas>but also should really check immediately after malloc

<stikonas>nor after s[0] = '.'

<stikonas>roconnor: can you make a patch?

<roconnor> https://github.com/oriansj/mescc-tools/pull/54

<roconnor>But doesn't the affect downstream implementations of M0?

<roconnor>*this affect

<roconnor>Which I assume are modeled on this code.

<roconnor> https://github.com/oriansj/stage0-posix-riscv32/blob/master/ELF-riscv32.hex2#L31C1-L31C75

<roconnor>03 ## e_ident[EI_OSABI] Set at 3 because FreeBSD is strict

<roconnor>This comment makes no sense to me as 3 is Linux and 9 is FreeBSD

<roconnor>at least according to https://llvm.org/doxygen/namespacellvm_1_1ELF.html

<roconnor>Is this a test? :D

<roconnor>See if people are reading?

<matrix_bridge><Jeremiah Orians> It is 3 because FreeBSD requires it to be 3 for Linux binaries to run on FreeBSB

<roconnor>ooooh

<roconnor>as opposed to 0.

<matrix_bridge><Jeremiah Orians> Which Linux doesn’t care if it was zero or 0xFF

<stikonas>roconnor: M0 and other assembly/hex programs are not too strict in terms of error checking

<stikonas>there are far more assumptions that we are in a good day scenario there

<roconnor>Including out of memory errors?

<stikonas>I guess

<stikonas>don't remember exactly

<stikonas>but even stuff like number of arguments is not validated

<stikonas>at least in some cases

<stikonas>(arguments to program)

<stikonas>well, let's look at M0

<stikonas>roconnor: yes, we just call malloc https://github.com/oriansj/stage0-posix-x86/blob/3b9c2bb6d4155e4f2e5f642b5e0f59255dfc5934/GAS/M0_x86.S#L190

<stikonas>and that's it

<roconnor>I guess in this case the program is probably going to trap in practice anyways

<stikonas>and in practive early programs don't need much memory

<stikonas>well, the biggest invocation is running on M2-Planet sources

<roconnor>except during development when they spiral into a unbounded loop of allocations (- -;)

<roconnor> https://github.com/oriansj/stage0-posix-riscv32/blob/master/riscv32_defs.M1#L186-L219

<roconnor>IMHO these immidate values would be better named rs2_in ... because _xn sounds like a register name.

<stikonas>roconnor: xn is a register name

<stikonas>though they are a bit misused as immediate value for shift operations

<stikonas>but other than that it is a register

<roconnor>oh

<roconnor>ha ha sorry. I only saw it used as immidate values for shift operations.

<xentrac>haha

<stikonas>x0-x31 are 32 registers of riscv

<stikonas>e.g. rs2_t6 is rs2_x31

<roconnor>I see now that the rs2_xn names line up perfectly with the other rs2_ names.

<matrix_bridge><Andrius Štikonas> GAS also allows usjng xn names

<roconnor>Sorry, everything I know about RiscV assembly is gleaned from reading https://github.com/oriansj/stage0-posix-riscv32 :)

<stikonas>sure, that's how I learned risc-v assembly

<stikonas>by writing stage0-posix-riscv64/32

<stikonas>with a some help from ekaitz and oriansj

<stikonas>(and of course by using risc-v isa manual)

<stikonas>it's long but most of the relevant info is in a few pages

<xentrac>the RISC-V unprivileged ISA manual is fucking fantastic

<xentrac>it's the best goddamned ISA manual I've seen in my entire life

<xentrac>and I often read ISA manuals on the weekends out of curiosity

<roconnor>what's an unprivleged manual?

<xentrac>the ISA is unprivileged, not the manual

<xentrac>there's a separate manual for the privileged instructions

<roconnor>privileged instruction as in ring whatever things?

<xentrac>well, mostly it's privileged data structures like page tables

<xentrac>yeah, but RISC-V doesn't have rings

<xentrac>but yeah. stuff you'd need for an OS kernel but not a regular user process

<xentrac>whenever you wonder why the RISC-V designers made some obviously stupid decision, all you have to do is read the unprivileged ISA manual, and they explain their rationale there

<xentrac>and it stops being obviously stupid, though it's rarely obviously the best choice

<roconnor>I should read it, but so far it is mostly makes sense, or at least from the software side of things.

<roconnor>I do feel bad for stikonas having to build an M1 assembler for load immidate w32 that gets split across two instructions.

<roconnor> https://github.com/oriansj/mescc-tools/blob/master/hex2_word.c#L67

<roconnor>in particular I find this value = value + 4; line really amusing.

<roconnor>so fragile. :)

<roconnor>the whole UpdateShiftRegister seems like a huge pain to have written.

<matrix_bridge><Andrius Štikonas> C version of M1 riscv support has actually been done by oriansj :)

<matrix_bridge><Andrius Štikonas> And possibly took a few iterations if i remember correctly

<xentrac>I find the two-instruction LI pseudo-instruction to be less annoying than old-style ARM's constant pools

<xentrac>although later Thumb2 versions switched to the approach RISC-V later adopted with a `movt` instruction: https://stackoverflow.com/questions/56229610/error-width-suffixes-are-invalid-in-arm-mode

<xentrac>which is the approach SPARC used from the beginning IIRC

<roconnor>What's a Thumb2?

<xentrac>Thumb2 is the revision of the ARM Thumb compressed instruction set

<xentrac>basically the story is that ARM was trying to compete in the microcontroller market in the early 90s against 8-bit and 16-bit CPUs, and at the time RAM was off-chip

<xentrac>so having a 16-bit data bus was a huge cost advantage for the 16-bit CPUs compared to most 32-bit CPUs

<xentrac>I forget if there was already an ARM that could use a 16-bit data bus or if they were considering making one

<xentrac>but they were facing the crushing prospect of requiring two memory fetch cycles to execute each instruction

<xentrac>so this guy who was leading the microarchitecture effort spent a weekend rewriting their compiler to compile to a smaller (and in most ways much RISCier) instruction set, 16 bits per instruction word instead of 32

<xentrac>when he was done, the resulting code was about 30% more instructions, and he was hugely relieved

<xentrac>because 30% more instructions of half the size was still only 65% of the required memory bandwidth (and required program memory size, which was another big advantage for 16-bit and especially 8-bit microcontrollers)

<xentrac>so that was "Thumb"

<xentrac>Thumb kind of sucks though

<xentrac>especially to write by hand, but also, like, 30% is kind of a lot, and you have more different kinds of registers for your compiler optimizer to have to take into account, and in theory all subroutine call destination addresses are dynamically computed, complicating branch prediction and also requiring an extra instruction cyle

<xentrac>*cycle

<xentrac>so Thumb2 fixed all that, more or less

<xentrac>RISC-V's "C" extension is sort of like a properly-thought-out Thumb2

<xentrac>without requiring the mode bit and bizarrely modified jump addresses that Thumb/Thumb2 require

<xentrac>interestingly ARM64 ("aarch64") dropped compressed instructions entirely

IRC channel logs

2026-05-17.log