<oriansj>and cc_knight-posix.s for stage0 is done <oriansj>(the benefits of a 45 line diff between knight-native and knight-posix) <vagrantc>identical i386 mes-mescc-static binaries in the debian packages. I'm sold. <oriansj>vagrantc: it gets better; universal cross-platform reproducibility <oriansj>no difference between an ARMv7l system or an x86 or Knight or PowerPC or RISC-V system when given the same input; they all generate EXACTLY identical output <vagrantc>obviously, you need differences for a binary to run on arm vs. x86 <oriansj>The M2-Planet, M1-macro, hex2 and blood-elf <oriansj>You have to specify --architecture and --$Endianness <oriansj>So identical input with identical arguments => always identical outputs <oriansj>hey dddddd (I'm doing a cc_* speed run for stage0) <oriansj>all that remains is ARMv7l (and AArch64 if you are ready) <dddddd>I'm going to continue finishing the branch in a minute, until done I hope. <oriansj>and cc_armv7l for stage0 has been prototyped <vagrantc>oriansj: uploaded mescc-tools 0.7.0-1 to debian ... that was a smooth update! :) <oriansj>vagrantc: it should build and run on BSDs just fine <oriansj>on Hurd it should build just fine but the tests might fail (I don't know how well Hurd handles Linux binaries) <oriansj>(I know BSDs usually have a compatibility layer good enough to run the tests) <vagrantc>presuming the compatibility layer is enabled... <vagrantc>Debian GNU/kFreeBSD is also one of the oddest of ducks <vagrantc>hurd-i386 built! kfreebsd-* still had an exec format error. <oriansj>also one thing about mescc-tools; if the second half of the test fails but the checksums of the tests are correct. It built correctly but it attempted to run a binary it didn't support <vagrantc>might be able to special-case the tests, then <oriansj>as I am not remotely familiar with how to detect if on kFreeBSD consistently <vagrantc>it's not a very well maintained port anymore, either ... though because it's so unusual it helps with cross-verification :) <oriansj>only took 3 Hours and 41 minutes to bootstrap 4 C compilers in Assmebly and C <oriansj>I challenge any other programming language to achieve that feat in less time <vagrantc>if there's a way i could call the tests differently for kfreebsd, that would be an option ... <vagrantc>oriansj: see the dpkg-architecture man page for more detail <oriansj>except we are trying to determine if a stage in a test should run (a shell script to be precise) <oriansj>as the gcc build version of the tools, should behave correctly; it is just the tests that need to have a stage skipped *vagrantc asks on irc.oftc.net #debian-kbsd ***fosslinux is now known as fossy
<dddddd>test/test99/hello-x86.sh: 49: test/test99/hello-x86.sh: exec_enable: not found <dddddd>exec_enables was removed in 5dc7acad7f4f of mescc-tools <dddddd>The amd64 script also tries to use it. <dddddd>Removing the call from the script: <dddddd>test/test99/hello-x86.sh: 49: test/test99/hello-x86.sh: ./test/test99/cc1: Permission denied <dddddd>For other archs the script is shorter, not trying the steps involved with final execution <dddddd>I'll cut that part in x86 locally for now <oriansj>dddddd: exec_enable can be replaced by chmod u+x <oriansj>dddddd: the tests are not used when bootstrapping <oriansj>only when doing development on existing systems <dddddd>OK, I'll complete the script for AArch64, using chmod and the final execution (arm7 and both knight lacks those) <oriansj>well because test99 is building C500 which is an x86 only C compiler <oriansj>The first step is just running it to self-host; the second step which is the self-hosting only works on platforms that can run x86 binaries directly <oriansj>(as C500 never included support for chmod since it is STDIN and STDOUT only <dddddd>OK, so no changes to the AArch64 script. <oriansj>So I'll be changing those tests (after I finish fixing the file-native.c for knight-native) <oriansj>darn; looks like M2-Planet has blown right past the 64KB budget leveraged by knight-native. Guess I need to tweak to support 2GB binaries <oriansj>looks like knight-native and knight-posix are going to become quite similiar <oriansj>knight-native now has the ability to self-host M2-Planet (cc-minimal.c) in 294,769,746 clock cycles <oriansj>or about a factor of 10 slower than the handwriten cc_knight-native.s which does the same job in 32,797,038 clock cycles <oriansj>you can verify this with: M1 --architecture knight-native --BigEndian -f High_level_prototypes/defs -f stage2/cc_knight-native.s -o scratch/cc_knight-native.hex2 && hex2 --architecture knight-native --BigEndian -f scratch/cc_knight-native.hex2 -o scratch/cc_knight-native && ./bin/vm --rom scratch/cc_knight-native --memory 10M <oriansj>M1 --architecture knight-native --BigEndian -f High_level_prototypes/defs -f ../M2-Planet/test/common_knight/libc-native.M1 -f tape_02 -o scratch/tape_02.hex2 && hex2 --architecture knight-native --BigEndian -f scratch/tape_02.hex2 -o scratch/M2 && ./bin/vm --rom scratch/M2 --memory 20M <oriansj>it of course will be trivial to write cc-minimal.c's for the other targets for M2-Planet. (just replace the line: Architecture = KNIGHT_NATIVE;) <oriansj>and replace the \n:STACK\n with \n:ELF_end\n <oriansj>I think that is enough for one night; good night. see you all bright and early ^_^ <fossy>i will greet you with a PR in your morning <dddddd>Exciting weekend. I need to sleep to wrap this up correctly. See you later, happy coding! <fossy>i think i have hit a v weird M2-Planet bug <fossy>will investigate in the morning <fossy>desired behaviour occurs in GCC however <oriansj>one must remember despite virtually identical syntax and virtually identicial behavior; M2-Planet and C are different in major ways. <oriansj>although I guess I could work to slowly eliminate those differences, until M2-Planet just becomes a standard C compiler (but god are C macros an abomination)