IRC channel logs

<oriansj>muurkha: you are completely right minus one detail

<oriansj>implementing that logic in hex0 -> M1 would be quite difficult but in C and above we probably could do that reasonably well

<stikonas>ok, we are getting fairly close to bootstrapping tcc on riscv64 :)

<stikonas>so we can do stage0-riscv64 -> mes-m2/mescc -> mes/mescc -> mes-tcc (which is already the first version build of tcc with some stuff disabled via ifdef flags) -> boot0-tcc (which is now tcc built with tcc) but boot0-tcc crashes

<stikonas>s/stage0-riscv64/stage0-posix-riscv64/

<matrix_bridge><Andrius Štikonas> (Thanks to janneke and ekaitz for the last fix)

<oriansj>it is great seeing the #guix-risc-v group progress ^_^

<muurkha>stikonas: that's awesome!

<muurkha>oriansj: yeah, I wonder if a low-level bytecode interpreter might be a usable way to do it

<oriansj>muurkha: yes but it would certainly require a good deal of cleverness to make one small enough to implement in hex0 on many platforms.

<muurkha>probably so

<oriansj>one would only need to encode load{8,16,32,64}, loadu{8,16,32,64}, store{8,16,32,64}, add, sub, shli, shri, call, return, jz, jnz and a couple knight halcodes (push and pop would certainly make the lower stages much easier)

<oriansj>if we make a register be the PC, we can eliminate separate call, return instructions

<oriansj>jz and jnz could be done with conditional add and conditional substract instructions.

<muurkha>if you make a register be the PC, yes

<muurkha>that doesn't impose the same level of avoidable waste on efficient emulation as something like memory-mapped I/O or memory-mapped registers (like the PDP-10), because you can statically identify which instructions touch the PC

<muurkha>you probably want some kind of bitwise operation

<muurkha>just on the theory that if what you're writing in this stuff is an assembler, you're probably going to want to extract bitfields sometimes? maybe that's more of a concern for a disassembler

<muurkha>a separate call instruction is still useful, though I guess you could replace it with something like addi lr, pc, #8; mov pc, r0

<muurkha>also how do you get from just add, sub, jz, and jnz to jg or ja?

<muurkha>not sure you really need all those varieties of load. ARM got by for quite a while with just LDM, LDR, and LDB, didn't it?

<muurkha>uh, LDRB

<muurkha>you left out MOV and load-immediate, but you can get them out of addi if you have a zero register

<oriansj>muurkha: well bitwise AND is handy but not *absolutely* required for bootstrapping; much like multiplication and division.

<oriansj>it just makes certain things faster, simpler and easier to reason about

<oriansj>and arm does have the different loads as otherwise you would have to sign extend or zero extend registers frequently

<oriansj>(you can see them in M2libc/armv7l/armv7l_defs.M1 )

<muurkha>they did eventually add more sizes of loads, it's true

<oriansj>Things like LDRH and LDRSH, LDRB and LDRSB are expected for 32bit architectures but 32bit loads doing signed vs unsigned doesn't matter but on 64bit systems it does matter

<oriansj>specifying signed vs unsigned 64bit loads would mean the architecture could be 128bits without any issues

<oriansj>but yeah, just 4GB of RAM is enough to get to TCC and Fiwix

<oriansj>anything bigger and we run into a great deal more complexity

IRC channel logs

2023-09-18.log