IRC channel logs

2024-05-14.log

back to list of logs

<stikonas>M1 and hex2
<stikonas>well, both assembly and C version is called hex2
<stikonas>unlike M0/M1
<roconnor>got it.
<roconnor>are the M1 and hex2 format's explicitly documented anywhere?
<stikonas>there is a bit here https://bootstrapping.miraheze.org/wiki/Stage0
<stikonas>but it's arch specific
<stikonas>e.g. risc-v uses those modifiers ! @ $ % & for other things than x86
<stikonas>but M0 is very simple, so you can just look at its source
<stikonas>I think the binary is about 2 KiB
<stikonas>and there is a C prototype... https://github.com/oriansj/stage0-posix/blob/master/High%20Level%20Prototypes/M0-macro.c
<stikonas>but if you can produce a more helpful documentation, that would be good
<roconnor>oh that is helpful. I was looking at the source and wondering what all the < and . were
<oriansj>roconnor: they have to do with padding
<oriansj>and in risc-v word alignment behavior
<roconnor>looking at the source of hex2.c, it makes it sound like risc-V is somehow even worse that x86.
<oriansj>roconnor: risc-v has insanely bad bit encoding; x86 is actually very simple encoding
<oriansj>if I did it in octal it would have much closer matched nasm
<oriansj>one thing we found is bit encoding documentation for RISC-V and ARM is backwards.
<roconnor>I was under the impression that whether bits are numbered from MSB to LSB or LSB to MSB isn't standardized.
<oriansj>true but if you are writing hex the standard if first char to last
<oriansj>and it would be odd to do 4bits + (4bit << 4) for the writing of bytes
<stikonas>risc-v is really hard to program for in hex0 but on the other hand, once you reach M0 it becomes far simpler than x86
<stikonas>as you can just have a short list of defines that can then express basically everything
<stikonas>(you encode individual things like addi there and not add_rax,rax like in x86)
<roconnor>Reading little endian hex values is kinda insane, so I can almost see why risc-V might flip the nibbles.
<roconnor>almost
<oriansj>and the bytes
<oriansj>stikonas: yeah, I really should redo x86 as octal; just can't seem to find the motivation to redo the early stages
<stikonas>oriansj: you could try to do higher level stages...
<stikonas>if you are not motivated with lower level
<stikonas>M2libc/M2-Planet would also need some adjustment to use octals defines
<matrix_bridge><cosinusoidally> oriansj: what would the octal encoding look like? Would you mix hex an octal. eg would you have a prefix for octal digits (eg ~) and then have the opcodes be encoded something like "add eax ebx" where eax was defined as ~0 and ebx was ~3 (in practice it may be more complicated since you'd have to write out all the fields of the opcode/modrm/sib)
<matrix_bridge><Andrius Štikonas> well, that's why I was suggesting that it's better to start with higher level stages...
<matrix_bridge><Andrius Štikonas> that way we would know what exactly we need to support