IRC channel logs
2021-10-09.log
back to list of logs
<fossy>janneke: does mes + tinycc work on amd64? i recall a while ago a couple of problems with it but i'm not sure what the current state is <stikonas>(--disable-java is probably not required but it's clearer and harmless) <oriansj>well getting hex2 for AArch to use the stack for output was easy but Read_char breaks fast <oriansj>the ! means to actually increment or decrement the register in question <oriansj>So I'm missing something and need to figure it out <fossy>stikonas[m]: i can repro your space error, i've made a small adjustment that might help, i will report back soon <fossy>stikonas[m], the fix gives enough space <fossy>i'll push it to a PR with a few other changes in a moment <stikonas>fossy: I've also noticed that in chroot mode umounting .../sysc/tmp often fails <stikonas>that's seems to be because of mount points inside sysc <stikonas>and we also need similar commits for hex2 and I guess M1 <stikonas>(those are less critical as it is just a warning for now) <stikonas>I've also spoke to laanwj and updated him on risc-v support in mescc-tools, hopefully he now would be able to make progress on porting mes to risc-v <fossy>yeah i have noticed that too, stikonas <fossy>I think we just need to unmount all those <Hagfish>i wonder if anyone has tried cross-compiling from risc-v to x86 <Hagfish>if you could build gcc that way, and it matched the hash of gcc compiled on x86, then that would raise the complexity of a trusting trust attack <stikonas>but it would still be nice to have full risc-v bootstrap <Hagfish>building up from mes to a cross-compiling gcc environment will be a nice achievement <stikonas>well, but for now everything after mes has to run on x86 <stikonas>after that you can just ask gcc to compile for anything <oriansj>stikonas: while that might enable upstream to be built with the new mescc-tools, there are a couple lines of change needed in MesCC proper to exec blood-elf, M1 and hex2. specifically this patch: https://paste.debian.net/1214862/ <stikonas>yes, I think it's actually these warnings that I was getting <stikonas> +> /usr/bin/mes-m2 --no-auto-compile -e main /usr/bin/mescc.scm -- -c -D HAVE_CONFIG_H=1 -I include -I include/linux/x86 lib/mes/eputc.c <stikonas>--LittleEndian is now depreciated and replaced by --little-endian <stikonas>And will stop working in a future releas <oriansj>yep, so that I can clean out the REALLY old flags. <oriansj>yeah it was the 0.6 release on 2019-04-14 when the new convention for flag names was official. So 2 years to fix (before seeing warnings) and another 6months before we pull out the flags entirely <oriansj>as a 2.5year warning should be sufficient for a 9 line delta <oriansj>well figured out what I was doing wrong with AArch64's hex2 <oriansj>it needs to be: str x1, [sp, #-16]! ldr x1, [sp], #16 to push x1 onto the stack and pop x1 off the stack <oriansj>but I guess it is what I get for rushing <oriansj>I kept trying to do str x1, [sp] #-16 to match ldr x1, [sp], #16 and ldr x1, [sp, #16]! to match str x1, [sp, #-16]! <stikonas>well, it's nice to eventually figure out the problem <oriansj>well I just updated the GAS prototype, now I have to translate that into M1, then hex2 and then update the hex1 but we will know for certain after all that <stikonas[m]>Oh yeah, we can't check until later. GAS version is always fast <oriansj>also I am doing this development on an AArch64 bare metal setup. So even the slow hex2 is still quite quick <stikonas>oh yes, I think on bare metal there is actually no or almost no difference <oriansj>total runtime: 1:51.57 so 2 minutes right now on a raspberry PI3 <stikonas>rockpro64 is slightly quicker... 1min 9s <stikonas>well, I don't expect this number to change much <stikonas>it's the qemu number that will probably go down by a lot <stikonas>oh, it needs new M1 definitions. riscv definitions do have an advantave that you only need to write them once <oriansj>stikonas: well AArch64 would have mapped much better to the word form of hex2 but was reasonabl enough that we managed to shoe-horn it into the old byte form of hex2 <oriansj>7:12.88 down to 2:03.27 So i would say yes it is a good improvement for AArch64 <oriansj>patch is up if you wish to verify yourself <stikonas>well, I'm not running some live-bootstrap work, so measurements might be skewed <oriansj>native is up to 1:52.97 from 1:51.57 so within margin of error <stikonas>there is still some slowness due to scratch but it's slightly harder to fix and in general things are not super slow now <stikonas>but yes, I can visibly see it faster when I run make test-aarch64 on amd64 machine <fossy><stikonas> well, but for now everything after mes has to run on x86 <fossy>only tinycc though. After tcc you could cross compile using gcc to any arch gcc supports <stikonas>fossy: I'm now doing some tests with autoconf 2.71, will have PR soon <stikonas>turns out it's a bit harder than just replacing 2.69 with 2.71. 2.71 needs full perl <stikonas>or at least doesn't run with our miniperl