<OriansJ>pder: it is the .answers file at the root directory which validates that every final binary was made correctly. you can update with Generate-${arch}-answers after a successful build. The SHA256SUMS files are for trying to figure out which step in the bootstrap is wrong (because its checksum is wrong) [Which also needs to be updated but it isn't as noticable as the default build reporting failure] <OriansJ>Hagfish: if we finish blynn-compiler's steps by the new year; we will have a core haskell fully bootstrapped. <yt_>uh oh. I've got a failing bootstrap on AArch64. looks like it is down to a63b883 in M2-Planet :( <yt_>got the unsigned comparisons done, though, so I'll get those up. <OriansJ>yt_: if you mean in mescc-tools-seed it is because I didn't have time to update the AArch64 checksums yet <yt_>it's not just the checksums though. M2-Planet compiled hex2 fails with a SIGBUS <OriansJ>if you checkout a63b883 in M2-Planet; do a make clean M2-Planet then ./test/test0104/hello-aarch64.sh <OriansJ>git checkout e5befc4feed411f55303c1fa014226b9d6017e29 && make clean M2-Planet then ./test/test0104/hello-aarch64.sh <OriansJ>then sha256sum test/test0104/kaem.M1 foo <OriansJ>so if test0104 (kaem.c) passes on AArch64 at commit a63b883; there is no way for it to fail on commit e5befc4feed411f55303c1fa014226b9d6017e29 as the output is bit for bit identical <yt_>hex2 with the arithmetic/logical shift right sees a bus error when trying to compile M1 <OriansJ>yt_: did you mean prior to a63b883 ? <OriansJ>because at that commit the diff is - DEFINE RSHIFT_X0_X1_X0 2028c09a and + DEFINE LOGICAL_RSHIFT_X0_X1_X0 2024c09a +DEFINE ARITH_RSHIFT_X0_X1_X0 2028c09a <yt_>Sigh. Looks like I forgot to add LOGICAL_RSHIFT and ARITH_RSHIFT to aarch64_defs.M1 in mescc-tools-seed! <yt_>So those don't get translated by M1, and chaos ensues <OriansJ>but using M2-Planet built M1 should give a user friendly error <fossy>OriansJ: i have found a segfault in cc_x86 <fossy>if you run cc_x86 on an empty file, it segfaults <fossy>likely for other architectures too <OriansJ>fossy: probably, it wasn't something I thought of when building cc_x86.M1 <OriansJ>but it should be realitvely easy to add a catch to make a user friendly warning <OriansJ>probably a 4-6line diff total per architecture <OriansJ>fossy: could you help me out and make a patch for me? <OriansJ>it probably would be somewhere either after CALL32 %read_all_tokens <OriansJ>yeah it would be a simple check for NULL in eax after CALL32 %read_all_tokens <OriansJ>and then simply display an error and jump to exit_failure <yt_>OriansJ: no problem. the hashes are with M2-Planet HEAD, so they might need regenerating <fossy>i am really inexperienced with M0/M1 as a language <yt_>fossy: you get used to it :D <OriansJ>well if it makes it easier for you a patch for the NASM version would also be helpful <OriansJ>debug_list will give you everything you need assembly wise to do it <OriansJ>yt_: your mescc-tools-seed work has been merged and I have updated M2-Planet to the latest commit in mescc-tools-seed; could you please regenerate checksums <yt_>all hashes are what they should be :D <siraben>OriansJ: oh wow, we got rid of the filter_haskell_output script entirely? <siraben>I was still working on that, heh, glad to see it resolved. <OriansJ>yt: nice thank you for all your hard work <OriansJ>siraben: well we do wish to get everything working in a fashion where we can just plop blynn-compiler into mescc-tools-seed and every architecture gets a working Haskell compiler <siraben>OriansJ: right, let me know when you update mescc-tools-seed with the unsigned fix so I can revert blynn-compiler's build to be based off of it <pder>siraben: now that marginally.c can be built, I am starting to modify virtually.hs to generate M2 Planet compatible code. If you want, I can try to make the output M2-Planet compatible, then based on the diffs, you could update the Haskell. <pder>I'm making slow progress, but I'm still pretty new to Haskell <OriansJ>pder: don't you mean the generated/marginally.c made by marginally.hs ? <pder>I'm having fun learning it though <pder>its actually the compiled virtually.hs code that prints the output that goes in marginally.c <pder>if I were to modify virtually.hs and type Make marginally.c, it would first build virtually_raw.txt then marginally.c <OriansJ>pder: well yes, it was a build dependency of marginally.c that updated <pder>Ive sometimes found it confusing which stage is affecting the output of other stages because there is no reason to the naming <siraben>pder: ok, let me know if you have questions etc and decoding GHC's type error messages can be tricky at first <OriansJ>pder: well we can rename *EVERYTHING* <siraben>pder: I agree, I'll take a look at your changes because I tried and failed to change things past efffectively.hs <OriansJ>also is it just me or are the contents of generated/marginally.c similiar to rts.c? <pder>Its quite similar. the run() is different and uses enums instead of characters. The list of enums is generated in the Haskell code <OriansJ>pder: enums are just numbers; so we could just use CONSTANTs/#defines <pder>Yeah, that is my plan. I just need help modifying the Haskell to generate these strings. <OriansJ>heck I could even define THING 67; instead of doing 'C' <OriansJ>So it would be a change in vm.c and just strip the C code generation out of the haskell <pder>Here is an example line: foldr (.) id (map (\(s, _) -> ("// CONSTANT _"++) . (s++) . ('\n':)) comdefs) <OriansJ>pder: you probably want to also include a #define too if you want GCC to also be able to compile the output <pder>The run() function is also created dynamically <siraben>pder: yeah, seems like what that line is doing is making [a,b,c,d] into // CONSTANT $a\n// CONSTANT $b\n... <OriansJ>siraben: // CONSTANT foo 10 is the M2-Planet way of doing constants instead of the #define foo 10 version done in standard C <pder>But I would want "// CONSTANT _A 1\n#define _A 1\n// CONSTANT _B 2\n#define _B 2 <OriansJ>as #thing in M2-Planet is a line comment and //thing in C is a line comment. So that what pder wants will work in both M2-Planet and GCC <pder>so some mixture of zip and map I imagine <siraben>pder: I've closed that redundant PR adjusting effectively.hs and pruned my branches related to it <siraben>pder: well not even zip is needed, I think just this part: (map (\(s, _) -> ("// CONSTANT _"++) . (s++) . ('\n':)) <OriansJ>now; we might not need that in virtually.hs if we tease out the actual unique pieces and put them into vm.c with a flag to enable them. <pder>Did you check out the modifications to the other .hs files? commit 8b2c4f5eb6bb1e7d9d7acf2649 <siraben>pder: yeah looks good to me, I wonder why it didn't work when I tried similar changes <siraben>change into, (map (\(s, _) -> ("// CONSTANT _"++) . (s++) . ('\n':) . ("#define " ++) . (s ++) . ('\n':)) <pder>siraben: how to add a counter to the enums? So it is // CONSTANT _E 5 <siraben>ah counter as well? definitely need to zip with upFrom 1 <siraben>i should note that the reason why lynn is using . (function composition) to concat strings is because of the encoding of strings as [Char] -> [Char] <pder>I dont understand the colon after '\n' <siraben>cons but partially applied by filing the left arg, so (x:) is like (lambda (y) (cons x y)) in lisp <siraben>to see why it typechecks, ('\n':) has type String -> String which composes of course with (s ++) of type String -> String <pder>I havent had much luck running it in ghc. Ive been doing a lot of trial and error just in the blynn-compiler <pder>OriansJ: I did something similar where I added a --foreign flag to vm to specify which version of foreign() to use <siraben>yeah it's probably best to iterate in GHC since the type checker will tell you exactly where things are inconsistent <siraben>pder: i'll make a branch that fixes the wrappers <pder>thank you, that will be very helpful <OriansJ>pder: if we consider the large blobby bits as bytecode and the haskell programs as bytecode compilers that just happen to include bytecode interpreters in their output; we could unify all of the steps and remove the need for flags for everything except bootstrap. <xentrac>as long as we can derive the bytecode from some non-bytecode input, right? <OriansJ>xentrac: well right now bytecode is used in the initial bootstrapping step <OriansJ>if I make matching changes in the Haskell and the VM run/foreign functions; then it all just becomes one big stupid bytecode vm; using bytecode to convert haskell into more bytecode <fossy>siraben: how much work do you think it will be in comparison to the haskell work to get scheme (yours or otherwise) running on blynn-compiler? <siraben>I'll probably spend more time building up the required libraries for the heap and so on <siraben>If that is too difficult, using the FFI will help relieve this <siraben>OriansJ: I will also look into removing need for the initial blobs <siraben>maybe after the entirety of blynn-compiler (up to the precisely stage) is bootstrapped <siraben>fossy: the haskell work has been relatively simple so far, pder and OriansJ are doing the work on the C side <siraben>i chose this style also because it's in the R5RS spec so it's readily verifiable ***ChanServ sets mode: +o rekado
<OriansJ>pder: will have a minor vm user interface change up shortly; I'll probably tweak it more later today <deesix>yt, continuing my review of DEFINEs in mescc-tools-seed/AArch64... <deesix>I think I caused some confusion by keeping the symbols SP-named when I started to use x18 as stack pointer in M2-Planet to fix (b2ece54864fc) the wasteful stack. <deesix>For example, now SET_X1_FROM_SP is defined both as 'mov x1, sp' and 'mov x1, x18' in mescc-tools-seed. <deesix>On the other hand, of course, there're the PUSH/POP definitions... some using x18 (with 64bits stack elements) and others with the same name using sp (and 128bits). <deesix>I did not look which file is using them and I guess there's coherent usage in each working program. <deesix>A quick look at some pre-M1 files shows that SP/128bits is used there, which explains definitions for the M1 implementations, I suppose. <deesix>yt, OriansJ, any thoughts? Which variant do we want at mescc-tools-seed/AArch64/aarch64_defs.M1? Do we want the same one elsewhere? <deesix>yt, I saw your note about LOAD_W0_AHEAD. I'll look how I came up with that encoding. <OriansJ>deesix: my thoughts: stack waste doesn't concern me but confusion and bugs do. so the question for you and yt is what will reduce the odds of future confusion and bugs when debugging and updating the files? <OriansJ>pder: I finally found a way to break up the pieces of raw into tiny chunks <deesix>OriansJ, I think having just one variant is safer, but it depends on how self-contained one thinks about the files are (and the projects copying files from each other). It easy to imagine adding definitions by copy and end up mixing variants. But I'm not sure if most files are not really expecting additions. <deesix>I'd be fine with reverting the optimization in M2-Planet and using the new variant from the low level implementations if that's easier. <deesix>Well, not so "new" variant but the original one (before we decided to stop wasting in M2-Planet) that is also used in the new low level (hex and so) implementations.