<OriansJ>yt: I can absolutely tell you are not an emacs whitespace mode user. <fossy>does anyone else other than me here not use emacs <fossy>what characteristic of the whitespace leads you to draw that conclusion <OriansJ>fossy: vim has a whitespace mode too <xentrac>trailing whitespace at the ends of lines presumably <OriansJ>I do tab indention and space alignment <OriansJ>so \tadd r0 r1 r2\space\space\space# comment <OriansJ>that looks universally consistent regardless of your tab size <xentrac>yes, it does. I meant "mixing of tabs and spaces too" <OriansJ>I also have sin running too; so unicode characters are like giant red flags <OriansJ>plus doing #\t instead of #\space\space\space to comment lines of assembly don't require messing any further with whitespace to keep everything lined up nice. <OriansJ>and if you cloned stage0 you can build your own copy of sin with: gcc High_level_prototypes/sin.c -o bin/sin <OriansJ>fossy: and for refernce I too am a vim user as well as an emacs user; they both have things they do better than the other. Never really cared for evil-mode though. <xentrac>I use vim for writing email or editing configuration files, emacs for programming usually ***scs is now known as Guest16503
<OriansJ>deesix: if it wouldn't be to much to ask; could you do a little double check for me <OriansJ>yt: there is a bug with postfix_expr_array_string_6 <OriansJ>it needs to be '00' not ' ' as M0 will just be dropping the '\'' which will result in the string being: "# looking up offset\n" instead of an empty string <OriansJ>but besides that and some whitespace issues; I see no problem with cc_aarch64.M1 and will be merging now with a small patch to clear out the issues <OriansJ>yt: all that remains is kaem and the steps in kaem form to complete the AArch64 mescc-tools-seed bootstrap <OriansJ>deesix: I only need an extra set of eyes to make sure I didn't miss something obvious with the DEFINEs ***scs is now known as Guest44817
<siraben>pder: interesting, runhaskell lonely.hs < effectively.hs works but if I compile lonely.hs using GHC and do ./lonely.hs < effectively.hs, I get an error about invalid argument to Prelude.chr <siraben>alright, so we should figure out how to get the generated lonely.c to compile <fossy>OriansJ: yt give me a ping when you do kaem and I'll review it <rain1>hey! pretty good here. just back from gym <OriansJ>still learning how to deal with the being a dad; everyday is a series of new learning experiences and challenging problems to face. <OriansJ>So lots of fun but moments where I wonder how could I be so stupid. <OriansJ>its great but it really kills a big chunk of my hacking time. <OriansJ>fortunately yt has taken up the AArch64 work; pder and siraben are taking the lead bootstrapping Haskell <deesix>OriansJ, sure. I'll take a look at the DEFINEs in cc_aarch64.M1. <siraben>OriansJ: do you plan on teaching your son math and programming? <siraben>OriansJ: it would be an achievement to actually bootstrap haskell for real, heh <siraben>Though of course, once we have blynn → mes-m2, that's it <OriansJ>siraben: well it is ultimately what haskell primitives are required to build GHC; once those are achieved, then that bootstrap will too be solved. <OriansJ>but first we have to get blynn done; then we can extend it until done. <OriansJ>or simply use it to write the next piece of the haskell bootstrap in a haskell subset we embed in blynn-compiler <OriansJ>we will have to deal with the contents of blob/ before the bootstrap will be done. Either by generation or pulling a hex0 and just commenting it to hell and back <siraben>I can ask around the GHC channels to see what the process is like <stikonas>siraben: on x86 and amd64 you can, aarch64 is still wip <yt_>OriansJ: I'm terribly sorry about the whitespace mess. I was using emacs' align-regexp to get the comments aligned properly, but that seems to enjoy inserting tabs while everything else is spaces... <yt_>thanks for fixing that up though <yt_>OriansJ: hmm I now see a hash mismatch for cc_aarch64, possible after the postfix_expr_array_string_6 fix? <yt_>I've included a fixed cc_aarch64 hash <OriansJ>siraben: yes once one has a scheme that is able to run MesCC; they are able to bootstrap GCC from it. <OriansJ>yt: no worries, all is a work in progress. and yes the addition of the null at postfix_expr_array_string_6 did change the checksum. I'll begin reviewing shortly (this should be done much faster) <yt_>OriansJ: kaem-0 is much smaller, thankfully! <OriansJ>yt: well yes; the bare minimal init/shell required to build everything <yt_>OriansJ: as with hex0, would you mind placing the kaem-0-seed into bootstrap-seeds? I should have the full bootstrap script ready when you have reviewed kaem <yt_>OriansJ: thank you :-) <yt_>OriansJ: ah, it looks like mescc-tools-full-kaem.kaem is still missing a copyright header <OriansJ>yt_: I'll fix that when I update the bootstrap-seeds in mescc-tools-seed <yt_>OriansJ: sweet, I'll pick them up then <OriansJ>yt: and merged; bootstrap-seeds updated and license headers added. All patches are up. Assuming no issues in the kaem scripts; AArch64 has been bootstrapped to the M2-Planet+mes-m2 level <OriansJ>I guess; I need to pick up the half done armv7l work in mescc-tools again. <OriansJ>(I did the GAS work; just needed to convert to M1 and so on) <bauen1>> is able to run MesCC; they are able to bootstrap GCC from it. <bauen1>does that mean that the nyancc finally got finished ? <OriansJ>bauen1: not exactly; right now the current path from scheme+MesCC is to build TCC and use that to bootstrap GCC <bauen1>OriansJ: nice, does that actually work yet ? (sorry i've been a bit out of the loop) <OriansJ>bauen1: yes; that has been working for a while now. (x86 and AMD64 only right now but armv7l is in progress for MesCC) <OriansJ>although I never got a copy of janneke's talk sources to include in the repo along with the rest of the talks. <deesix>OriansJ, yt_, a brief first look at all of the M1 DEFINEs in mescc-tools-seed/AArch64 (not just cc_aarch64.M1, as all of them is just a bit more work) I'm finding some minor duplication (as in the same instruction and different symbol). objdump dissasemble is matching quite nicely so far, as expected, but I'm yet to finish comparing. <deesix>For example, the somehow more explicit STR_BYTE_W3_[X1]_1 is also defined elsewhere as TST_X1_7. ADD_X0_X0_X14_LSL4 has a version with an extra underscore (the later is like the similar ADD_X0_X1_X0_LSL_3). <yt_>deesix: the TST_X1_7 DEFINE sounds like a copy-paste errror, that should not be identical STR_BYTE_W3_[X1]_1 <deesix>I'm adding the recent kaem-minimal.M1 to the bunch (It took a while to mirror). <OriansJ>deesix: thank you for double checking. <deesix>yt_, it seems so, consume_token_pad seems the origin of the error, I guess (in a couple of hex2 implementations). <yt_>deesix: with that bug, looks like consume_token_pad will always write two null bytes, but not actually align x1 <yt_>I suppose nothing actually depends on that alignment, so the bootstrap still works <yt_>I'll have a fix for that in just a minute <yt_>deesix: nice find though! <yt_>deesix: OriansJ: fixed & added to the pull request. it only changed the hash of hex2-0 <OriansJ>yt: will review shortly (still reviewing your last patch) <yt_>OriansJ: no worries, take your time <OriansJ>now I guess all that is left is making the world aware. <OriansJ>I leave the Public Relations work to yt and siraben; <OriansJ>as I am sure the Haskell work will grab people's attention. <OriansJ>bootstrapping A C compiler, a scheme interpreter and a haskell compiler from hex <yt_>OriansJ: is the Haskell work going to bootstrap into Mes (and MesCC) or is it "just" to Haskell? <OriansJ>oh and it works on multiple architectures <OriansJ>yt_: first goal is to get it the stage that GHC and it can build matching behavior. After that the Mes and Haskell work can be done in the order which makes the work easier. <OriansJ>as siraben believes they can solve the scheme bootstrap problem with it. <OriansJ>And when someone else is willing to save me the work; I let them <yt_>OriansJ: ah I can see a few Scheme compilers in Haskell floating around so that makes sense <OriansJ>It has been more than 4 years of hard work and lots of failed paths. But the final step is always just out of grasp. <OriansJ>mes-m2 if it could just overcome the macro problem would solve the bootstrap but I can't figure it out. <yt_>It does seem like a very complicated path to bootstrap to GCC. But I suppose that once there is *a* path, it can always be simplified. <yt_>OriansJ: yeah, I had a brief look at mes-m2 as well, but couldn't wrap my head around it. <OriansJ>with work TCC could be converted into M2-Planet form (I just haven't gotten to do that work yet) and solve the bootstrap that way (straight from M2-Planet -> M3 -> GCC) <yt_>OriansJ: what is the M3 in that? <OriansJ>yt_: M3 was 3 pieces writeen in M2-Planet's subset of C: a proper ELF linker, a GAS compatible Assembler and TCC converted to exporting GAS assembly output and using M2-Planet's C subset. <OriansJ>The Linker and Assembler to be in binutils compatible form; so that MesCC can benefit from it and speed up its porting process. <OriansJ>and the converted TCC to make future porting match the current M2-Planet porting process (simply add strings) <OriansJ>yt_: well actually that piece is nearly done (it is the ELF linker); just need to add the bit that writes the final binary. <OriansJ>it was sort of the "screw it" plan if the scheme requirement becomes unsolvable <OriansJ>hence the interest and work in blynn-compiler instead as it looks like less work. <yt_>or at least more interesting work, so more people are interested in doing it :D <OriansJ>yt_: honestly if siraben and pder were not involved in the Haskell work; it would have been unlikely for me to have found it or make as much progress as they have managed to do in such a short amount of time. <OriansJ>They are excellent and doing impressive work and blynn-compiler clearly demonstrates that. <OriansJ>all I did was start on the C code conversion and they managed to run with it.