IRC channel logs
2020-12-01.log
back to list of logs
<pder>I took a stab at getting blynn-compiler working with M2-Planet. It is currently working up to the point of loading classy.hs <pder>The main issues were pointer arithmetic as oriansj pointed out. I also found some strangeness with the behavior of FUNCTION pointers <V>definitely going to grow up to become a hacker <pder>Throughout the code, the run function takes two arguments which are functions. In functions like fp_get, i had to move some local declarations out of the function and make them global. <pder>I wonder if this behavior is similar to how you cant declare a local inside a loop <siraben>pder: passing the function pointers causes issues? <pder>The script to build and run is in my branch named go.sh <pder>If you look at the diffs, I had to move local variables out of str_get and fp_get. There was some strange misbehavior where those variable assignments were not working <fossy>pder: is this on top of VM.c changes that OriansJ already did <pder>fossy: yes, that is correct <pder>I just pushed another small change to blynn-compiler that now successfully runs vm without arguments to generate "raw" <fossy>how long did it take when compiled by m2-planet? <pder>on my old laptop the M2-planet version of vm takes 57 seconds to run vs 7 seconds for the vm compiled with gcc -O2 <OriansJ>rain1: we probably could do something similiar with kaem.hex0 for the bootstrap <OriansJ>pder: thank you so much for the help ^_^ <OriansJ>well it is certainly possible that FUNCTION pointers are not properly cleaning up after themselves but we probably need to figure out a test to fix it. <OriansJ>rain1: probably ending with mes-m2 or guile as the init but that is just a fun idea to play with. (thanks to gash and gash-utils) <pder>Thanks, oriansj. I will see if I can create a minimal test case to illustrate the problem. If you check my commits, I basically had to make some of the local variables in the function called by a function pointer global in order to work around the issue. <OriansJ>pder: very impressive work as you single handedly got us 60% to the end goal with these commits <pder>I think the next step is making rts.c M2-Planet friendly. It also appears several of the .hs files in the last stages have some duplicated C code as well. <OriansJ>and some changes to the generated C code as well; which is where FUNCTION pointer behavior problems in M2-Planet will really need to be addressed. <OriansJ>and once we complete that, we can make bylnn-compiler a submodule for mescc-tools-seed <OriansJ>and siraben will help us to a scheme able to finish the bootstrap <OriansJ>as ultimately we will need to ensure blynn-compiler behavior is consistent across all architectures that M2-Planet+mescc-tools support <OriansJ>I just triple checked and the output of the working vm2 for RAW is 9732a8852bf92b4097f275da4ceba3b718138a5e16190cbef43bbd4be42a27dd (which is exactly the same generated by GCC, clang and the original version of blynn compiler) <OriansJ>now I am checking if lonely.c is the same as what the GCC version makes