<Hagfish>the article itself requires javascript, so i don't know if it's worth visiting :) <OriansJ>pder: very impressive work; looks like just some minor clean up and everything else can be done in Haskell (and possibly in M2-Planet) <OriansJ>siraben: once you strip out the C code bit from the earlier stages; it'll all be M2-Planet code generated by Haskell code and we can just delete rts.c <pder>Thanks. I think that the last three or four stages the Haskell will need to just need to be modified to generate M2-Planet compatible code, which means removing the enums and replacing them with CONSTANTS, turning the switch statements into if-else and I think siraben already wrote some code to populate the prog array one element at a time. <pder>Yeah, so far, go.sh is not using rts.c at all <OriansJ>pder: so we probably should eliminate it entirely <OriansJ>and once I finish updating M2-Planet; you'll be able to eliminate the -1 special case as M2-Planet should do proper compares. <OriansJ>although looking at generated/marginally.c it looks kinda familiar to the rts.c case <OriansJ>I've decided that a fixed heap offset for knight-posix in libc-core.M1 is probably a bad idea long term; so I've tweaked the stage0 vm to allow the user to specify a desired stack stize and put the HEAP after that. but will default to a 64KB stack <OriansJ>matching changes in M2-Planet to shortly follow <siraben>pder: I adjusted assembly.hs and the output hash matches <pder>siraben: would you be able to share your changes? What did you change with assembly.hs? <siraben>pder: Yes, I'm testing it and will PR <pder>Thats great, thank you. I think we should be able to follow the same pattern up to marginally with each of the .hs files. <siraben>wait a bit before merging, I'm fixing the CI for that branch <pder>I will also adjust the Makefile so the gcc build works <pder>Since we are no longer outputing C code in these stages, we could just do -o lonely_raw.txt <siraben>Ok patching guardedly and patty fail, I'll be pushing to this PR until it works <siraben>pder: which branch did you patch patty.hs? <pder>I dont think I ever touched patty.hs, only lonely.hs. Commit ed88f0a84cce9e487 <pder>I'm going through each hs up to marginally and applying your output changes, then altering go.sh and the Makefile <siraben>Oh dang, the way the wrap files are written, they can be used to patch the other haskell files without touching them <siraben>pder: ok, I'm pretty sure the issue I'm running into with patty is the unsigned comparison <rekado_>I see there’s new Haskell activity since last time I stopped by <rekado_>could someone perhaps write a summary of the planned route to bootstrapping GHC so that we can put it on bootstrappable.org? <siraben>I've asked GHC people about bootstrapping GHC and it's not looking likely, GCC has to be bootstrapped anyway <siraben>We're taking this Haskell route to complete the C -> Scheme step <pder>siraben, have you fetched from oriansj or myself? If so you shouldn't have an issue with patty hanging <pder>with commit 807cc371741b46e7 you should be able to run go.sh and build up to marginally.c <siraben>Very strange, it looks deleting parts of patty.hs changes the value of d in rts_reduce(d) <siraben>pder: could you explain what the structure of this means? ./bin/vm -f guardedly.hs --rts_c generated/patty_raw.txt -o generated/guardedly.c <siraben>we are running guardedly.hs using patty_raw's bytecode and putting the output into generated/guardedly.c? <pder>siraben, it means using guardedly.hs as an input file run the patty bytecode and output guardedly.c <pder>equivalent to ./patty < guardedly.hs > guardedly.c <siraben>I'm stuck trying to make patty not need filter_haskell_output, I'll try again tomorrow. <pder>siraben, yes, I actually noticed the modification to effectively.hs outputs a different parameter for rts_reduce, and the prog array does not match <pder>now that I think about it, if you modify the Haskell, the bytecode should change, so maybe it is not a problem ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<rekado>siraben: oh. A Haskell detour to get to Scheme? Huh. <rekado>so GHC bootstrapping is still an unsolved issue, basically where I left it a few years ago <fossy>an odd detour, I agree, or I used to think so at least <rekado>back then we didn’t have a need for GCC 2 in Guix, so I didn’t consider using it to build the GHC 4 rts <rekado>but now we have GCC 2 for the early bootstrap anyway, so I guess I should revisit this <fossy>didnt you think using an older gcc might help with the nhc95 thing? <rekado>I think the nhc route is a dead-end <rekado>I got as far as I had to for the blog post, but there were no good clues from there on <rekado>the general approach might still work: GHC partially interpreted by Hugs, used to build itself. <rekado>but for that to work I need to build the GHC 4 rts libs first and tell Hugs to use them. <rekado>my memory on this is spotty, but I made some notes when it was all fresh <OriansJ>pder: working on the unsigned compare in M2-Planet right now; I should have x86 and AMD64 done tonight and armv7l tomorrow (I'll need deesix or yt's help with AArch64) but it should be a pretty simple patch for them to do. <OriansJ>siraben: thank you for the patch. it is merged <OriansJ>rekado: honestly Haskell is looking like a smaller problem then syntax-case in C as we made major progress in just 1 month. <OriansJ>we already are up to a rather impressive subset of haskell supported; <OriansJ>only a handful of blob like pieces to address and once it becomes self-hosting; then we are in another class of possible solutions. <OriansJ>pder: the M2-Planet update for unsigned behavior in x86 is up <OriansJ>just make sure to copy the updated test/common_x86/x86_defs.M1 as I am using seta setae setb and setbe <OriansJ>please make sure that it solves the unsigned comparison problem for you and if not let me know and I'll try something different.