IRC channel logs

<oriansj>rickmasters: sorry for the delay (bootstrap-seed reviews are a bit more manual) merged

<stikonas>oriansj: hmm, we need a changelog entry for this in stage0-posix... Do you think I should put it in a new bootstrap-seeds category or part of x86 ? (https://github.com/oriansj/stage0-posix/blob/master/CHANGELOG.org)

<stikonas>hmm, maybe it's fine to add it to stage0-posix-x86 section...

<oriansj>new bootstrap-seeds seems most accurate

<stikonas>ok...

<stikonas>let's do that

<stikonas>and I guess I'll move those other seed changelog entries to it

<oriansj>well seed changes do have bigger security impacts and thus called out seperately seems wise.

<stikonas>that's fine, let's do that

<stikonas>oriansj, rickmasters: stage0-posix changes pushed

<stikonas>(CHANGELOG.org is also updated)

<stikonas>oriansj: perhaps when you tag other repos such as M2-Planet, mescc-tools, etc we could add a version to changelog too?

<stikonas>e.g. M2-Planet 0.11 instead of M2-Planet or something like that

<oriansj>stikonas: I have been doing git tag -as -f Release_${version} Release_${version}

<stikonas>thanks! I had a bit more progress on riscv64 port of mes but now going to bed

<stikonas>still need to convert more stuff before it can even build hello world

<stikonas>but after that it's probably not far from building mes

<rickmasters>Debootstrapping without Archeology: Stacked Implementations in Camlboot https://arxiv.org/pdf/2202.09231v1.pdf

<rickmasters>Not sure if this has been posted before but it appears to be directed towards this community.

<muurkha>I think I saw it previously

<[exa]>lovely though.

<muurkha>I'm happy to see it again :)

<rickmasters>Apparently I've been "debootstrapping" this whole time and didn't know it :)

<stikonas[m]>rickmasters: I think the author was or still is in this channel

<Irvise_>Hi all, I am going to throw a small request in case someone feels like fulfilling it.

<Irvise_>Could someone add the x86 assembly keyword movsd to TCC? I think it would be just adding a simple line here https://repo.or.cz/tinycc.git/blob/HEAD:/x86_64-asm.h#l134 like the ones below.

<Irvise_>I have never contributed to TCC and I am not knowledgable to try and do it myself :S

<muurkha>that sounds like a good idea! but I'm less knowledgeable than you

<Irvise_>It would be something like this commit https://repo.or.cz/tinycc.git/commit/9cfc8f60ce195ccf53b261096e2deb915484646b

<Irvise_>I think it was someone in here that did it because I said that TCC did not support those instructions either.

<Irvise_>I mean, I can always learn, but I have other things :s

<drakonis> https://ratfactor.com/forth/the_programming_language_that_writes_itself.html this post is mostly offtopic but its good

<drakonis>its also not quite finished, however it is on its last stretch

<muurkha>it's a pretty fun page

<stikonas>Irvise_: none of use here contributed to TCC as far as I'm aware

<stikonas>janneke: had most contacts with them when he was patching tcc 0.9.26 to make it buildable with mescc but those patches were not accepted upstream

<stikonas>and when musl was using some instruction that tcc didn't support I actually patched them in musl (locally in live-bootstrap)

<Irvise_>Oh, then maybe it was somewhere else...

<Irvise_>I expected the TCC people to be more open minded, but maybe they do no longer care about old releases.

<stikonas>I seem to recall something like "it's better to improve bootstrap compiler than simplifier tcc"

<stikonas>s/simplifier/simplify/

<[exa]>Irvise_: this looks like it should do the same https://repo.or.cz/tinycc.git/blob/HEAD:/x86_64-asm.h#l435

<Irvise_>Yup, the extra "s" probably indicates a different register type only.

<[exa]>it's "move a single doublefloat" and that instruction def there looks... oh no wait it's for move dword

<Irvise_>I am going to sleep now, but I'll try to answer any questions or messages tomorrow. GN ^^

<stikonas>hmm, it's probably SSE stuff...

<[exa]>Irvise_: anyway the common approach is to just find the opcodes for the instruction, then read how that macro there actually works, and just fill in the numbers

<janneke>stikonas: actually, dannym upstreamed arm patches for tcc

<stikonas>janneke: while you are here, I have another question

<stikonas>so the old style define had syscalls encoded in the define name, i.e. asm ("li_____%a7,SYS_write");

<stikonas>would it be fine if I just used a number now? I.e. asm ("rd_a7 !64 addi"); // SYS_write

<stikonas>alternatively I could include syscall.h and construct 64 from the string

<stikonas>but it's probably less readable

<stikonas>(this particular example is from lib/linux/riscv64-mes-mescc/_write.c

<janneke>stikonas, in general we like identifiers better than magic numbers with a comment, but i'm guessing this is for exit, read and write only?

<janneke>but there are no hard rules, if it becomes overly complex to use a define/identifier, then yeah

<stikonas>yeah, I think just those

<stikonas>previous define has just hidden all complexity in the M1 define file

<stikonas>it's not like it was reusing it from syscall.h...

<stikonas>I'm not too sure why these exit read and write are different from others though

<stikonas>actually just exit and write

<stikonas>anyway, I now need to convert crt1.c (which unfortunately is not well commented)

<stikonas>and after that I think I'll be able to run scaffold/hello

<stikonas>(with the current version of mescc-tools)

<janneke>stikonas, right; sounds as an improvement now, as unsatisfactory as it may seem at first glance

IRC channel logs

2023-05-18.log