IRC channel logs

<Guest91>I have some questions about https://github.com/oriansj/stage0-posix-amd64/blob/master/hex0_AMD64.hex0: Why does the first instruction use rax instead of rdi? Why is the loop_reset_all jump target (line 76) and the xor instruction on line 77 necessary? On line 72, is ebx (sign extended on line 73) guaranteed to be positive? If it isn't, maybe the fd

<Guest91>returned from open could be sign extended--not an actual suggestion, just pointing it out

<matrix_bridge><Andrius Štikonas> Guest91: hi

<Guest91>I just noticed the comment says the fd should be sign extended, along with another instance of a comment disagreeing with the code on line 142

<matrix_bridge><Andrius Štikonas> First instruction uses rax because that's where we want to store number of arguments

<matrix_bridge><Andrius Štikonas> 2nd and 3rd are both rdi because we don't care about program name

<matrix_bridge><Andrius Štikonas> So we save it to rdi and immediately overwrite it

<Guest91>I was asking because rax (argc) is also discarded

<matrix_bridge><Andrius Štikonas> Guest91: oh that might be because we want to initialize rax

<matrix_bridge><Andrius Štikonas> I.e. make sure high bits are 0

<Guest91>Well, it's overwritten by another pop rax instruction

<matrix_bridge><Andrius Štikonas> Later we often use short instructions e.g. cmp al instead of cmp rax

<matrix_bridge><Andrius Štikonas> Hmm, perhaps any other sparr register could be used there then

<Guest91>I was thinking maybe it's because the instruction is shorter on x86?

<Guest91>But I haven't checked

<matrix_bridge><Andrius Štikonas> All pops are one byte

<matrix_bridge><Andrius Štikonas> Well, x86 register pops

<matrix_bridge><Andrius Štikonas> New ones such as pop r14 are two bytes

<Guest91>It's minor, but using rdi instead of rax would make it immediately obvious it's discarded. Writing discard instead of get in the comment wouldn't hurt either

<matrix_bridge><Andrius Štikonas> Might be copy paste from kaem

<matrix_bridge><Andrius Štikonas> I think there it ia not overwrtitten

<matrix_bridge><Andrius Štikonas> x86 also does that...

<matrix_bridge><Andrius Štikonas> https://github.com/oriansj/bootstrap-seeds/blob/cedec6b8066d1db229b6c77d42d120a23c6980ed/POSIX/x86/hex0_x86.hex0#L64

<matrix_bridge><Andrius Štikonas> Any riscv has none of that https://github.com/oriansj/bootstrap-seeds/blob/cedec6b8066d1db229b6c77d42d120a23c6980ed/POSIX/riscv64/hex0_riscv64.hex0#L73 since we just access stack by offset

<matrix_bridge><Andrius Štikonas> Not pop one bybone

<Guest91>Why is kaem called kaem?

<matrix_bridge><Andrius Štikonas> Anagram of make according to oriansj

<Guest91>I have some questions about cp or mescc-tools-extra in general, too, but maybe I should talk to someone in private, if that's possible, to not spam the channel too much

<Guest91>Oh, that's cool

<Guest91>I presumed as much and was already fond of calling the scripts kaemfiles

<matrix_bridge><Andrius Štikonas> Probably better here

<matrix_bridge><Andrius Štikonas> More people can answer

<matrix_bridge><Andrius Štikonas> I'm not home yet right now and will be offline soon

<Guest91>have you looked at what I reported about M2-Mesoplanet? can you reproduce "M2-Mesoplanet --debug-mode 15 --preprocess-only --architecture amd64 --operating-system Linux -I stage0-posix-1.9.1/M2libc --file stage0-posix-1.9.1/mescc-tools-extra/catm.c --output catm.M1" failing, "M2LIBC_PATH=stage0-posix-1.9.1/M2libc M2-Mesoplanet --debug-mode 15

<Guest91>--preprocess-only --architecture amd64 --operating-system Linux -I stage0-posix-1.9.1/M2libc --file stage0-posix-1.9.1/mescc-tools-extra/catm.c --output catm.M1" succeeding?

<Guest91>I should have cloned master for this, but the result is the same. Is there an easy way to fetch stage0-posix including all submodules?

<Guest91>Never mind, it's in the readme

<Guest91>By the way, really nice work on hex0!

<Guest91>Everything made sense in the end and I wasn't able to improve anything. Didn't read the code until the very end, just debugged and ported to macOS

IRC channel logs

2025-10-16.log