<stikonas>Hagfish: if you look at diffs, they are fairly small <Hagfish>that reminds me of the famous story about the plumber who taps a pipe and charges the home-owner $200 <oriansj>stikonas: I've merged your M2-Planet work. <oriansj>and i am guessing the updated M2-Planet is needed for the x86 version to work <stikonas>that's just unrelated M2-Planet improvement <stikonas>might be useful if at some point we want to rebase mes-m2 on top of newer mes... <stikonas>in mes-m2 PR that you just merged I think I've used #if defined and then #else followed by #define <stikonas>in principle on can go back to #ifndef now <oriansj>you might want to add support for #undef and #error to clear out the current build warnings <oriansj>perhaps you are right in the adding of features until we can just use mainline mes.c <stikonas>yeah, I thought about those too, just didn't get to those yet <stikonas>oriansj: perhaps the best is some hybrid approach <stikonas>but we might still get some simplifying patches into mainline mes <stikonas>hmm, one of the more complicated issues is that mes uses a lot of function like defines <stikonas>something like #define TYPE(x) g_cells[x].type <stikonas>anyway, I might try to add support for #undef and #error instead <stikonas>gbrlwck: so mes-m2 riscv support was just merged <gbrlwck>i'm reading it in the backlog :) nice! <stikonas>I tried playing a bit with env variables (like MES_ARENA) but they don't seem to help <gbrlwck>i guess i'll have to set ARCH=riscv64 now. and also ELF_HEADER ? why are they distinct? <gbrlwck>./bin/mes-m2 -c (display 'Hello,M2-mes!) (newline) <stikonas>they are different because on x86 elf header is ELF-i386-debug.hex2 <stikonas>gbrlwck: if you run it a few times, you should get some working attempts <gbrlwck>i built with `ARCH=riscv64 ELF_HEADER=riscv64 make clean mes-m2-boot` <gbrlwck>trying 10 times it always fails pretty fast <stikonas>kaem --verbose --strict --file kaem.riscv64 <gbrlwck>it's the same when i `kaem -f kaem.riscv` <gbrlwck>trying again with --verbose and --strict now <stikonas>strange, I only get maybe 50/50 crash/workign <gbrlwck>stikonas: would you mind pasting some hash of ./bin/mes-m2 ? <gbrlwck>compilation does not fail (altough kaem does not crash when mkdir doesn't work) <gbrlwck>and i'm not too pleased with `mkdir -p bin` part, because when we use the bootstrapped utilities '-p' is not an option (so it creates a directory "-p"). -p is there so make does not fail, right? <gbrlwck>tests (`make test`) fail and gdb gives a "BFD: warning [..] section extending past end of file" <stikonas>gbrlwck: ec838cf09b9334252012447a62a77733b89a4a80b3f2da47835a47c68120d888 bin/mes-m2 <stikonas>yes, bootstrapped mkdir does not implement -p <stikonas>but yes, you need -p for corutils for it not to fail <gbrlwck>ok, i have a completely different file <gbrlwck>b2143add588e443e55828f6ddf4dcb3720cd36fb <stikonas>ok, that branch is now deleted but b2143... should be fine <stikonas>which is newer than what stage0-posix pulls in <stikonas>or maybe you need git switch master before git pull <stikonas>(checksum failures are expected after that <stikonas>I don't think I've used my newest features, but I definitely needed oriansj's #else fixes <stikonas>before that preprocessor did not work correctly for #if #else #endif <Thalheim>is there a recent recipe for using tcc (mob) to build gcc 4.7.4? I'm getting stuck in gmp with errors like "mul_1.c:41: error: 'SIZEOF_MP_LIMB_T' undeclared" <stikonas>Thalheim: and so far we only tried on x86 <Thalheim>I'll quickly check if 0.9.27 makes any difference; I'm on x86_64 do you mean 32-bit x86? <Thalheim>ah! I think I found a new channel that will consume all of my time, thank you. <stikonas>live-bootstrap is basically automated build script from hex0 to gcc 4.7.4 and beyond <stikonas>but so far x86 only, and some steps are not working even on amd64 <stikonas>other arches (amd64, aarch64, riscv64) are only done for stage0-posix part which bootstraps from hex0 to M2-Planet (which is a subset of C compiler) <gbrlwck>i updated stage0-posix, rebuilt mes-m2 but it's still another hash as the one you pasted and /only/ gives segfaults <gbrlwck>also gdb still gives the same "section extending past end of file error" <stikonas>M2-Planet 7a7bfd4529dbcdb87c1717d08489aec861fc0f4f ? <gbrlwck>ahhh.. no, it uses the one in stage0-posix: 55929d4ddf27a51bcbad47c2f6d618ce629aa5e6 *gbrlwck is wondering why `guix pull --recurse-submodules` did neither help nor hint <oriansj>hmm the checksums have been changed across the board. That is something concerning <stikonas>in my two commits, I think something with the ordering <stikonas>if you look at two commits combined, I think only test1000 changes <oriansj>well M2-Planet's checksum should update but everything else should stay the same unless there is a different behavior <stikonas>remember, I implemented support for ANSI ! <stikonas>so it emits different assembly instructions <stikonas>I guess almost everything used ! but mostly for 0 and 1 values <oriansj>well yes, match and !match are used frequently <stikonas>I think in fact kaem conditionals do rely on full support for ! <stikonas>although, I guess so far we haven't used them <stikonas>but anyway, if we go for upstream mes, it uses ! extensively and also for non 0/1 <oriansj>doing an artifact compare confirmed only the predicted M1 changes in output and no side effect changes in the binaries produced. <oriansj>(except for M2-Planet which had additional changes but that is expected.) <gbrlwck>i guess i'd have to add the stat() function to M2libc <stikonas>just if program finds "-p" argument, simply ignore it and don't do anything <gbrlwck>but then no dirs would be created and the next step in a kaem script would probably fail, no? <stikonas>it does fail if directory already exists... <stikonas>well, mkdir was written mainly for live-bootstrap <gbrlwck>i think it's in many (if not most) kaem.run scripts <stikonas>well, ask oriansj if we want to add a new dependency on stat <stikonas>but yes, I did find it slightly annoying to have different behaviour <stikonas>but mescc-tools-extra's mkdir is very simple compared to coreutils one <stikonas>same with cp (it does not preserve executable bit, does not support dot as in 'cp a .', etc <gbrlwck>my intention was never to add all possible features to mkdir, just the -p that i kept stumbling on <stikonas>actually, this mkdir exists with 0 even if it can't create directory <stikonas>so I think you really can just ignore -p and patch will be much simpler <stikonas>something like if(argc > 1 && strcmp(argv[i], "-p") == 0) i = i +1; ***stikonas_ is now known as stikonas
<stikonas>and I've updated stage0-posix (and hence M2-Planet) in live-bootstrap.