<oriansj>fossy: here is what was thinking of doing tomorrow: I write https://github.com/fosslinux/mescc-tools/blob/minimal-debug/kaem.c (with my suggested changes) in NASM and then convert to M1; which will drop the size probably by a factor of 2-4. Which should be small enough (and a low enough of a bootstrap unless you think I need to take it down to hex0; which will take an extra day to do) <fossy>oriansj: I think M1 would be fine <fossy>I will make those improvements you suggested tonighy <fossy>that will allow you to do that tomorrow ***ChanServ sets mode: +o rekado
<oriansj>fossy: I think you are going to love the new kaem-minimal.M1 <oriansj>THe NASM version is entirely complete; one second as I upload that for you <oriansj>Now I found a bug in kaem where after the execve it should be EXIT_FAILURE not EXIT_SUCCESS <oriansj>So 362 lines of assembly with comments <oriansj>a few more for the macro definitions <fossy>o.O that's great under 1024 bytes <oriansj>depending if I wish to optimize inner function jumps I could get it under 800 bytes <oriansj>although there is only one bit of it that I am not sure I did correctly (preserving of envp and passing it) <oriansj>MOstly because I never had to deal with envp in assembly before <oriansj>But that'll be trivial to fix (if I did it wrong) <oriansj>I probably should add a hex0 version after you get a chance to play with it a bit <oriansj>M1 --architecture x86 --LittleEndian -f x86/Development/kaem-minimal.M1 -o bin/kaem-minimal.hex2 <oriansj>hex2 --architecture x86 --LittleEndian --BaseAddress 0x8048000 -f x86/ELF-i386.hex2 -f bin/kaem-minimal.hex2 -o bin/kaem-minimal --exec_enable <oriansj>sha256sum 0581692a85a2149b5942b0648800d5deee76ace6ca12e669add1687043911718 bin/kaem-minimal <oriansj>fossy: please play with it and make sure you are happy with it <oriansj>while I add some neglected high level prototypes <fossy>oriansj: on a different matter, how many months of work do you think mes-m2 is away from running mescc/gash/gash-core-utils? <oriansj>fossy: that however is harder for me to estimate probably 1-4months depending how hard I go at it <fossy>would i be correct in saying that currently guile cannot run mescc? <fossy>so i'll just have both guile and mes avaliable for gcc-seed for now and then substitute mes-m2 for both when it is ready <fossy>because i'm moving gcc-seed from busybox to gash{,-core-utils} <oriansj>fossy: no; guile can run MesCC it just requires some environmental variables set if I remember correctly <fossy>that means we can have just the one binary <oriansj>and swap out that binary in a single step when mes-m2 is done <fossy>it will be interesting to see which is faster, mes or guile <oriansj>bigger team and more time spent optimizing <oriansj>Oh it also JITs and Compiles; instead of just interprets <fossy>what does --no-auto-compile do? <oriansj>fossy: it turns off guile's default behavior to compile scheme files that it gets <fossy>i hope that getting a statically linked guile will be less painful then mes was :| <fossy>i guess guix and gcc-seed are almost both doing a full scheme bootstrap <fossy>however gcc-seed isn't using slow-utils, it's using the M1/hex2 etc from hex0-seed <oriansj>I just have to make a production grade scheme (probably mostly by myself) in a massively reduced C subset (that I have to bootstrap on a bunch of arbitrary platforms) <fossy>oriansj: of course, it's not going to be easy <fossy>i wish i could help more lol <fossy>i could learn scheme but that would take me a while <oriansj>I just need scheme programmers willing to just make reasonable tests for the primitives <fossy>oriansj: if you can point me to a good scheme tutorial that you know of, i can likely try to make some tests for primitives <oriansj>fossy: now that is a bit of a problem <fossy>but, i come from a C background <fossy>so, i would have difficulty writing good tests in all likelihood <pder>Is there any desire to have armv71 and aarch64 ports of hex0, etc in mescc-tools-seed? <oriansj>I wouldn't turn down someone wiling to help <pder>So for example with aarch64, support has been added to M2-Planet and cc_aarch64 now exists, so it would be a matter of implementing hex0, hex1, hex2 to be able to bootstrap similar to how x86 or AMD64 is done? <fossy>oriansj: also i think i need to say thank you to you... you've been so helpful in helping me to understand how all of this works and you've pulled the heavy lifting for almost all parts of the low-level bootstrap (hex0->mes-m2) and it seems like you will be the one who will finish the bootstrap with mes-m2 <oriansj>pder: hex0, hex1, hex2, M0 and cc_aarch64.M1 (since the current cc_aarch64.s is not written in AArch64 assembly) <fossy>oriansj: what is cc_aarch64.s written in then? <oriansj>fossy: knight assembly language to run on bare metal when I implement in TTL <oriansj>that way I can jump to M2-Planet and build a posix for AArch64 without having to depend anything but hardware <oriansj>However no one is interested in the VM work yet (except for markjenkinswznc who is awesome) <oriansj>and a bunch of posix work so that people can just leverage their existing hardware and operating systems <fossy>i see that bin/vm is good for testing stage0 <oriansj>simpler target, no gotchas and oh yeah better hardware primitives <fossy>but im unsure how it is useful for the bootstrap on a non-knight system? wouldn't it still have the same kernel/microcode/firmware trust issues as hex0-seed and be a larger seed? <oriansj>but people want bootstraps on POSIX systems; hence why mescc-tools-seed was created <fossy>from knight you can build binaries for other architectures correct <fossy>so where is the ideal point to break from knight to the other architecture? <oriansj>sure it has to trust big fat kernals, huge bios and firmware blobs but atleast is hardware they have now <fossy>so the idea would be that from cc_* onwards you would use the target architecture? <oriansj>so I simply duplicated the effort and wrote the steps in POSIX x86 <fossy>why dosen't mescc-tools-seed just leverage bin/vm up until cc_*? <oriansj>fossy: originally yes but as you can see; I am compromising so that other people can feel better about it all <fossy>oriansj: lol, i honestly don't get what people's problem is with using bin/vm up until cc_* when it is pretty much completely transparent to them <oriansj>because it is another new generated binary <oriansj>the work has been done for x86 and amd64 <fossy>you are right, leave those issues in the past <fossy>let's just keep moving forward <oriansj>anyone who wants to save me from the grief when ARM people start complain about how they have to depend upon x86 for their bootstrap; is more than free to do that work for me. <oriansj>because I know that is going to show up eventually <pder>I asked about that earlier because I thought it would be an interesting learning exercise for me <fossy>OH NO I HAVE TO USE A DIFFERENT ARCHITECTURE TO DO MY BOOTSTRAP <oriansj>pder: and you will absolutely learn alot about how ARM compilers lie <oriansj>honestly, it is fine if people don't like that and just do the work themselves (for fun, learning or whatever) <oriansj>It is when they feel entitled to my time, which annoys the crap out of me. <fossy>your time is your time and you should be able to choose what you want to do with it <oriansj>asking nicely is fine; demanding just makes them a dick <oriansj>for the people who help out of the goodness of their own hearts (or any selfish reasons they have); thank you for sharing the work <oriansj>fossy: now if you wanted to leverage your C skills to path blaze the bootstrap to solve more; there is a task you might find challenging <oriansj>well do need a posix that M2-Planet can build <oriansj>would you be perhaps interested in helping with that problem? <fossy>that would be very interesting <oriansj>that way we can remove linux/BSDs from the bootstrap binaries <fossy>hm i would be happy to have a crack at that <fossy>i will need to read up a bit on kernels tho <oriansj>and if M2-Planet can build it; we can bootstrap it from metal <fossy>x86 + coreboot + this would be a good intermediete between x86 + bios + firmware + linux and knight <fossy>of course, knight would be better <dddddd>kernel work is in my radar too, I'd be glad to help there. <fossy>but for those who don't have the time or money a open source bios + this would be better than having a fat-ass kernel <oriansj>It only needs to support the current M2-Planet syscalls <oriansj>virtual memory and round-robin multi-tasking <oriansj>possibly ext2 filesystem (or fat32 depending on difficulty) <dddddd>About the need for scheme tests, I still don't quite get the reason of not using some test suite (I guessing here, but they must exist) from some other implementation. <oriansj>It needs to work on multiple host architectures (which require different syscall numbers and methods) <oriansj>dddddd: yes there are and they are very implementation specific and sadly mes-m2 isn't able to support guile's yet <oriansj>as guile jumps straight to depending upon alot of features <dddddd>maybe from [very] earlier versions...