<OriansJ>personally I look forward to guix having a scheme-only bootstrap <Hagfish>1.44 meg to 512 BYTES? that's fantastic! <Hagfish>i'm starting to wonder whether it's possible to have fractional or negative numbers of bytes :) <Hagfish>apparently it's possible to fit 385 arbitrary bytes into a tweet using base2048 encoding <xentrac>you can easily have fractional numbers of *bytes* <xentrac>fractional numbers of *bits* usually requires something like arithmetic encoding, though that depends on context <OriansJ>Hagfish: yes hex0 will fit in a tweet. kaem-minimal 2 tweets min <Hagfish>it could be an interesting type of publicity, but there wouldn't be space in the tweet to provide the context for why those particular bytes were useful <Hagfish>perhaps, once there is something to announce, there could be an official news/blog post explaining what's been achieved, <Hagfish>and a separate post that's more fun, pointing to the first post and saying "here's what hex0 would look like as a tweet" <Hagfish>give the post a clickbaity title like "bootstrapping all of Linux from a single Tweet", or something :) <deesix>Hagfish, the 1.44M -> 512b is just a [mostly empty] floppy image truncation, nothing changed really. <OriansJ>deesix: indeed. a more impressive feat in bootstrap-seeds was when fossy got the C code version of kaem-optional-seed from 16,246bytes down to 7,228bytes. I had to resort to Assembly programming to make any improvements on that. Fortunately M2-Planet doesn't generate optimal code and some creative choices got it down to 737bytes after I incorporated fossy's reductions. <janneke>OriansJ: finally found the m2-planet floating point bug; just sent a mail; or see my gitlab <OriansJ>janneke: all M2-Planet binaries can be gdb debugged. <janneke>OriansJ: yeah, what happened? something fubar on my side? <OriansJ>well the change was to sign extend an integer into EDI/RDI if it was signed or just put 0 in EDI/RDI if unsigned. <OriansJ>which is what GCC does when doing idiv <janneke>but something must be different, because gcc (and mescc ftm) do not create a mes binary that hits a fpe <OriansJ>GCC literally just drops the divide entirely <janneke>are you able to see the disassembly? <janneke>i see your segfault, but i'm blind here <janneke>(other than set disassemble-next-line on) <OriansJ>yeah just fine, you did test/common_x86/ELF-i386.hex2 instead of test/common_x86/ELF-i386-debug.hex2 <OriansJ>objdump -d shows everything fine after as does gdb <janneke>that's probably my problem with mes too <janneke>ah, wait: i'ts using DIV with CLTD, isn't that wrong? <janneke>i think the result must always be < 32bit for DIV and < 31bit (signed) for IDIV <janneke>so, it's interpreting dx:ax as an unsigned number (very large) <janneke>and after div with 1 or 2, that's > 32bit <OriansJ>janneke: well if you div by 2 it works <OriansJ>oops I forgot the .section before the .text <nimaje>why mov 0, %eax and then xor %eax, %eax ? shouldn't both of them set %eax to 0? <OriansJ>switching between gas and nasm assembly throws me like that <janneke>yeah, the windows convention is terrible for us unix beards <OriansJ>technically it is Intel vs AT&T conventions but oh well <janneke>ah, always blamed the windows folks on stackoverflow :-) <OriansJ>honestly, I just blamed AT&T for being lazy and not using the assembly syntax that wasn't standard for the hardware platform they were building binaries for. It would have been a couple weeks of work but then the hardware companies could be responsible for extending the assemblers when new instructions were added. <OriansJ>idiv ebx => divide by 1 no problem; div eb => floating point exception <janneke>yep, i tried to suggest something like that <janneke>for DIV you need to xor edx, for idiv ctcl may be used (but can still overflow) <OriansJ>So I got signed and unsigned division on x86 backwards? <OriansJ>oops; easy to fix just need to fix the DEFINEs as I had DIVIDE_eax_by_ebx_into_eax F7FB and DIVIDES_eax_by_ebx_into_eax F7F3 <OriansJ>as sign extensions is correct for signed and 0 is correct for unsigned <OriansJ>now to check AMD64 to see if I made the same mistake there <OriansJ>I guess that just goes to show how rarely I have division in my programs. <deesix>Maybe you also want to check if AMS64 needs this fix too, I think it does, OriansJ. 608fba306f46128fe901302f813d139c635e996a <OriansJ>deesix: yep atleast I am consistient when it comes to making mistakes <OriansJ>I keep making the same typos over and over again <OriansJ>janneke: I pushed a fix, please verify it works for you <janneke>hmm, /me should prolly not say that... <janneke>well, one full build succeeded, just to be sure i'm running another one <janneke>OriansJ: oops, another fpe near the end of the 2nd build <janneke>so it's "a lot better", but seems more problematic than my revert patch <janneke>i'll have a better test with the revert one <janneke>it's terrible that it's nondeterministic; how to catch the problem in gdb?? <janneke>yup, inconclusive but another good build with the revert, and another failure with the idiv/div swap <janneke>but again, near the end of the build <OriansJ>janneke: you know you can diff the M1 outputs right? <janneke>i'm assuming the diff would be what we expect...but it's worth a look <OriansJ>janneke: you know you can use tools like meld or emacs to manually patch the broken M1 output with the working M1 output to find exactly the one where it isn't function right? <janneke>OriansJ: shall try to bisect these differences? it's going to take quite some time, esp. as the swap fix not always fails after a ~10min build <OriansJ>your patch doesn't swap div and idiv definitions <janneke>yeah...but apparently mes' code base isn't doing stuff like that ;-) <OriansJ>well for all 32bit numbers without a top 1 bit CDTQ simply converts EDX to 0 <OriansJ>for example 0x7FFFFFFF just sets EDX to zero <janneke>as we're note dividing by 0, the exception must be an overflow <janneke>i'm working to resurrect/finish the full-source-bootstrap in guix based on the revert patch; meanwhile i'm trying to bisect the mes.M1 differences <OriansJ>except if your DEFINE is still the idiv <janneke>these ascii M1's (and hex2's) are a real life saver at times <janneke>OriansJ: looking to see if that's any better... *janneke goes to make some supper <OriansJ>These wait 10 minutes to see if the fix works cycles have to be frustrating. <janneke>yes..it's OK to do it as a side job but having all your attiention on that is terrible <janneke>OriansJ: 3 consecutive correct builds, so i guess your fix is great! sorry for the noise... <janneke>oh crap, now the m2-planet-boot fails to build; that worked with vanilla 1.7.0 <janneke>how could i be so optimistic and update both bootstrap-seeds and m2-planet at the same time? <janneke>well, i guess bootstrap-seeds can't be the problem <janneke>yup, 1.7.0 + b7c14a2 Looks like I got x86/AMD64 signed and unsigned division backwards works <janneke>so, there's a problem somewhere in 1.7.0 wrt bootstrapping <janneke>i mean, somewhere between Release_1.7.0 and HEAD <OriansJ>janneke: you know you can replace bootstrap hex2 with mescc-tools hex2 and it'll give you a verbose error message <janneke>so i have to setup a non-guix development environment for that... <OriansJ>janneke: it only needs a git clone --recursive and nothing else <OriansJ>it appears to not have a FUNCTION_main <janneke>meanwhile, i found why my m2-planet mes had an elf problem; previously m2-planet produced mes-compatible M1 <janneke>and i used lib/x86-mes/elf32-header.hex2 <OriansJ>looks like cc_x86 can't compile the new file.c <janneke>hmm, gcc-compiled m2-planet now bootstraps mes correctly, but the bootstrapped m2-planet fails <OriansJ>looks like the file buffering for x86 is not cc_* compatible at all. <OriansJ>I really should include a --bootstrap option to M2-Planet and flag on the use of primitives that cc_* don't support to catch these errors sooner <OriansJ>janneke: I'll have M2-Planet in a buildable shape for you shortly <janneke>does M2-Planet come with a kaem script that builds it using M2-Planet? <janneke>i'll first inject the gcc-built M2-Planet binary into the bootstrap, to find where the problem really is <OriansJ>janneke: test1000 builts M2-Planet and then has its output build itself for x86 <OriansJ>and I'll have an updated mescc-tools-seed up for you shortly <janneke>trying the gcc-m2-planet injection first, if that works i'll add an extra test1000 package (or stage ...hmmm) <OriansJ>janneke: M2-Planet built M2-Planet should behave identically to GCC built M2-Planet <janneke>i'm now building guix' mes-boot with an injected gcc-built M2-Planet, looking pretty good <janneke>the bootstrapped M2-Planet (without the test1000 self-build) certainly does not behave as well yet <janneke>i must have missed this step last time and stopped after i got a bootstrapped M2-Planet, and a gcc-M2-Planet built mes :-( <janneke>OriansJ: the gcc-built M2-Planet does not use M2-Planet's libc, right? <janneke>i mean, an honest bug could be anywhere... ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<OriansJ>janneke: M2-Planet doesn't technically have a libc. As all the libraries are just standard source files read during compilation <OriansJ>as the libc-core.M1 just sets up the stack and calls FUNCTION_main and syscalling exit if it returns <xentrac>a library of source code is still a library ;) <OriansJ>ooops looks like I forgot to update modulus too <janneke>i just had another unexpected failure ... not sure if fpe or something else <janneke>i could even have been testing 64bit M2-Planet, unintentionally... <janneke>very difficult to be 100% correct in a development environment <janneke>anyway, i'm very happy that we're close enough for telling a good story, even if we're not 100% done <OriansJ>janneke: if you find something where M2-Planet built M2-Planet doesn't produce bit for bit identicial output as the GCC version of M2-Planet. Raise a major flag as that is something I absolutely have to fix <janneke>OriansJ: hmm, yes, installing the m2/mes.M1 source is a good idea <janneke>i'm doing that for the mes-built output, should do that for m2-planet built output too <OriansJ>janneke: mescc-tools-seed builds M2-Planet and has it self-host itself <janneke>OK, so no need for an extra package -- hmm <OriansJ>everything else I have taken care of for you <OriansJ>I'd even incorporate mes in it too if I knew an exact commit which would work <janneke>ah no, i'm keeping mes a separate package <janneke>also, we cannot use git in a bootstrap build <janneke>so, the guix m2-planet-boot package needs to have multiple tarball sources <janneke>i guess for porting to new systems, e.g. for fossy, this is real convenient -- first to understand and possibly adaapt <janneke>meh, i'd like separate tarballs better, preferrably released tarballs <OriansJ>janneke: mescc-tools-seed has a pattern for new systems too <janneke>=> /gnu/store/mq9nw4jp0qngq3jhhyq4krjdxldqw0zv-mes-boot-0.22-303-g54e1ebad9 <janneke>(but with the gcc-built m2-planet hack) <OriansJ>simple sha256sum should show matching results <OriansJ>yt: I am going to need your help with updating the aarch64 checksums of mescc-tools-seed in a little bit <OriansJ>janneke: also note they are just git submodules <OriansJ>speaking of which, I really probably should try to get bootstrap-seeds into savannah <janneke>we should probably rename mescc-tools-seed, it's become a misnomer i guess <janneke>i'm quite happy with that, real small separate seeds <janneke>mescc-tools-seed is now a source-only package, right? <OriansJ>janneke: that is correctly the only binaries are in the bootstrap-sseds submodule <janneke>=> /gnu/store/21dbdsc0v7ivm141xf50pd6fb8n7zhsi-mes-boot-0.22-303-g54e1ebad9 <janneke>(this is with the gcc cheat, but we can compare lib/cache/mes.M1) <OriansJ>yt: could you please update the AArch64 mescc-tools-seed