***wowaname is now known as opal
<yt>OriansJ: fossy: I've just noticed that mescc-tools-seed/{x86,AMD64}/mescc-tools-full-kaem.kaem are missing a copyright header <OriansJ>ytt: I'll start the review shortly and fossy could you please take care of the copyright header issue please and make a pull request? <OriansJ>yt: one thing you might not have noticed in M1 is <2 willpad 2 nulls and <500 will do 500 nulls <OriansJ>So people wouldn't need to do large blocks of '00' <OriansJ>and hex2 just has bare < which will pad to architectural alignment. <OriansJ>It was done so people doing armv7l didn't have to keep figuring out or fixing alignment; hex2 will just insert nulls and fix up the addresses accordingly. <siraben>I am now able to build blynn-compiler using mescc-tools-seed. Impressive stuff! <siraben>So we have a bootstrap from a few hundred hex bytes to a subset of Haskell <siraben>OriansJ: how should generated/lonely.c be adjusted so that M2-Planet can compile it? I can edit the Haskell code in effectively.hs to do this <yt>OriansJ: you're right, I didn't notice that hex2 feature, that would've been quite handy <yt>I ended up moving all the strings to the data section at the end so I didn't have to worry about alignment in the text section (at least in cc_aarch64) <yt>AArch64's hex2-0 doesn't have this feature either, so I'd have had to deal with it in the final hex2 files anyway ***yt` is now known as yt
<siraben>if needed I can also change `sizeof(prog)` in `unsigned prog_size=sizeof(prog)/sizeof(*prog);` line to a calculation in effectively.hs <OriansJ>siraben: an easy way to know was to just do M2-Planet --architecture x86 -f file and if you see M1 code; it'll work (likely) <OriansJ>yt: fair but it would have made your Developer files easier to write <siraben>Oh looks like the declarations at the top need to be updated <siraben>oops, it wouldn't work in normal gcc because of the array assignment <siraben>OriansJ: opened a PR that removes dependencies from blynn-compiler to only mescc-tools-seed <pder>Regarding blynn-compiler, I am wondering if the simplest approach to dealing with that prog array is to just read this data from an external file. I tried changing unsigned prog[] to char *prog but found that M2-Planet does not allow string literals longer than 4096 <siraben>hm pder left can they still see messages <siraben>can't we just malloc the array and assign the members? <rain1>why don't you extend the max length of literals ? <pder>I was thinking along the approach that OriansJ suggested, where we dont repeated compile each step after lonely. Instead vm would be run with arguments to load the "prog" array and a .hs file to execute and it would output another prog array that is used in the next step. This eliminates the need for rts.c and recompiling each time. <pder>vm has -l or --load-rom to load a file containing a comma separated list of numbers <siraben>pder: perhaps, but that would require larger changes to the haskell files, it's much easier to adjust the output of effectively.hs to complete the chain <siraben>also let me know if you see these messages, on the Matrix bridge I see leave/join <pder>siraben: yeah, I am not entirely sure what is the most straightforward route. rts.c needs some more work to be buildable by M2-Planet, and OriansJ has already moved some of this functionality into vm.c