<fossy>im unsuprised it detects linux <pder>When bootstrapping using kaem, should I assume that shell redirection is not allowed? <mihi>pder, as far as I know, kaem does not handle shell redirection, it only parses environment variables, looks up the binary and calls execve. But it should still be possible to call something from kaem that redirects streams (or redirect the streams when you call kaem) <OriansJ>mihi: I'll review your merge shortly <OriansJ>fossy: mine is: Intel(R) Core(TM)2 CPU P8600 @ 2.40GHz (notice the big difference between built by GCC and M2-Planet) the benchmark number is when M2-Planet is built with GCC. <OriansJ>mihi: honestly I never considered cygwin as I have no Microsoft systems personally and use virtualization on my work computer. <OriansJ>pder: shell redirection just has not been implemented yet in kaem but fossy would be the expert as they did most of the work. <OriansJ>mihi: but you are correct, I did strip out string functions in M2-Planet to eliminiate conflicts with MAX_STRING being a global variable instead of a fixed constant. But impacted programs can be updated to have their own custom version without much trouble. <OriansJ>I'm guessing GCC would drop that block entirely <pder>OriansJ: still struggling with comparisons even with latest M2-Planet build. Now there is a regression and patty hangs <OriansJ>pder: I hope I didn't reintroduce the wrong signed/unsigned behavior <OriansJ>(I really should get some proper tests for that in M2-Planet) <fossy>Shell redirection is on my adgenda <OriansJ>fossy: I attempted to copy the sha256.sh solution to Kaem/test.sh to address mihi's issue with test 14 of kaem on on the de_DE.UTF-8 local system <fossy>ok, thanks, ill check it out in a sec <OriansJ>yt: a change in mescc-tools (hex2) that requires a reordering of 2 of the steps 7 and 8 in mescc-tools-seed. (and have kaem use mescc-tools version of string.c instead of M2-Planet's) I'll have x86 and AMD64 fixed up shortly ***xwvvvvwx- is now known as xwvvvvwx
<nimaje>OriansJ: because NULL doesn't have to be the value 0 <siraben>OriansJ: I see, if you or pder can produce a diff showing the desired output I can adjust the Haskell as needed. <siraben>Hagfish: the project is picking up, lots of cross-collaboration! <siraben>The good thing about using Git and various tools is that the history is well tracked and would only need to be collected and summarized <siraben>and of course prior work by OriansJ, janneke et al. set the foundation <mihi>OriansJ, good catch. It used to be malloc and I forgot to drop the loop when changing it to calloc... And as nimaje pointed out, in-memory representation of ((void*)0) does not match that of ((uintptr_t)0) on some exotic architectures, but I assume nobody would want to use those for bootstrapping anyway... <mihi>OTOH when changing the hash table size from 49157 to 65536 (65537), I would not call that a reduction. The value is from some old academic paper which suggested to use primes in the middle between to powers of two as hash sizes for optimal collision minimization, but I guess the practical benefit for a faster "clamping" operation outweighs the theoretical benefit :) (the double clamping was to avoid said bug in <mihi>mescc and could probably have gone once that was fixed) <mihi>and my gut feeling is that gcc does not optimize the loop away as jump_tables is not a local variable and it is hard to argue that there can not be any side effects while main is running... And indeed on my machine, the loop is clearly visible in the -S output. *janneke just managed to "bootstrap" tinycc on ARM <janneke>that's still the reduced binary seed bootstrap <yt_>OriansJ: I'll have the corresponding AArch64 changes up in a minute <OriansJ>nimaje: true on those systems NULL is 0xFFFFFFF and calloc sets memory to 0xFFFFFFF <nimaje>why does calloc set memory to something other than 0? calloc should always set memory to 0 as it can't know the type <OriansJ>nimaje: because some memory types default to 0x00 and others 0xFF and calloc is to return what would be considered unused memory (or atleast cleared to behave like unused memory) <OriansJ>mihi: I would just like to personally thank you for helping me complete the objectives for the mescc-tools v1.1.0 release. <OriansJ>Today is the official release of mescc-tools v1.1.0 with meaningful performance improvements for both M1 and hex2; which significiantly reduce the build time for janneke 's mes.M1 bootstrap seed and all binaries made by MesCC <OriansJ>with the BSD compatibility enhancements thanks to nimaje, kaem enhancements thanks to fossy, AArch64 enhancements thanks to yt and the big speed improvements in hex2 thanks to mihi. ^_^ great job everyone. <OriansJ>oh and VagrantC's debian GCC 10 work <pder>woohoo, well done everyone! <pder>I pushed some more updates for blynn-compiler to the methodically branch. We can now build up to crossly.c using M2-Planet and mescc-tools. Make sure you are using the latest M2-Planet <pder>Still need to investigate some signed/unsigned comparison behavior that differs from the gcc build. I had to reintroduce my workaround in vm.c for now. Only three more stages of the compiler bootstrap to go <OriansJ>yt: your improvements have been merged <OriansJ>pder: you are correct it appears unsigned behavior is showing up where it shouldn't <pder>yt_: very nice. Do you or anyone know what else is needed for mes-m2 to be able to host mescc? <OriansJ>pder: last I checked once macros and modules are done and MesCC is tweaked to use the guile compatible primitives that mes-m2 provides (eg clear out a few of the hacks) it should be fully functional <OriansJ>(basically make MesCC believe it is running on guile and not Mes) <OriansJ>If there are any primitives that are missing because I made a mistake, make a test using guile and that primitive and I'll make mes-m2 match that behavior <OriansJ>basically I was using Ur-Scheme as a test of mes-m2's macros (as it is just literally guile -s compiler.scm) and gave up when I just couldn't figure out what was actually wrong <OriansJ>it works fine for 70% of it but got stuck at "ERROR: not equal ((x y . z) (x y . z))" <OriansJ>unwinding scheme to C primitives is not very fun for me. <OriansJ>but once that is done; mes-m2 is significantly faster than mes.c (especially when compiled with GCC) and runs in less memory because it is a compacting scheme and not a stop and copy. <OriansJ>So it'll significantly reduce the guix bootstrap time