IRC channel logs
2020-12-18.log
back to list of logs
<OriansJ>and the build for raw in blynn-compiler is now in much smaller pieces <siraben>OriansJ: Just saw your commits, looks good! <pder>Thanks for your work on blynn-compiler OriansJ. What does the option --rts_c stand for? I wonder if this could be clearer <siraben>pder: I think I'll move my PR to OriansJ's master so everyone's branches can just rebase <siraben>OriansJ: I have rebased my branch and opened a PR on your master <yt_>deesix: OriansJ: I think my slight preference is towards standardising on the wasteful stack using SP. I found it helpful when debugging that objdump and gdb were matching what the M1/M0 macros were saying. <yt_>on a related note, I've been wondering if it is possible for M2-Planet to maintain a frame pointer and a chain of (minimal) stack frames (just LR and FP) and if that would be enough for gdb to generate stack traces <deesix>yt, I don't know what gdb needs for stack traces; maybe OriansJ knows. As for the matching asm, do you mean something more like 'str x0, [sp, #-16]!' instead of PUSH_X <deesix>0? 'mov x8, #0xd6' instead of SET_X8_TO_SYS_BRK? What about the "ahead" and "skip" sets, that objdump prints with actual addrs? Maybe I'm reading too much and you only <deesix> talk about the sp/x18 confusion... <pder>siraben, thanks for your work on the ghc wrappers <siraben>pder: no problem, as always would be happy to answer questions <siraben>i've been reading some of the Haskell code recently and oh my it's such a powerful subset <mihi>hi OriansJ et al, are you interested in contributions to mescc-tools(-seed) that "only" make the bootstrap (significantly) faster? All tests on x86 32-bit linux. <mihi>First I changed hex2_linker.c to use a hash table instead of the linear jump_table list (similar to how M1 does it) and it improves hex2 speed compiling m2-planet on itself by 33% (or 80% when using gcc-compiled hex2) <mihi>then I tried to rewrite hex2_linker (named fasthex_linker) to use pointer lookup tables instead of the if cascades (due to a lack of optimized switch statement) and it saves another 75% when built with gcc, but unfortunately does not build with m2-planet... <mihi>And last I implemented I/O buffering in functions/file.c, which improves the hex2 speed (and also speed of other tools) when compiled with m2-planet by another 80%. But that one either requires a function call to opt-in or change of all tools to properly fclose() their fopen()ed files... <mihi>all in all, >90% of the mescc-tools time (so M1, blood-elf, hex2) is spent in hex2, so I looked at optimizing that one first <mihi>blood-elf could also get a cosmetic fix that avoids reversing the jump table, but I doubt the speed increase is noticable <mihi>before I try to clean up my current mess and send pull requests, I wanted to ask if you are even interested in them. They do add some complexity to the bootstrap code, but on the other hand they make working with the tools much faster. <mihi>some questions about M2-planet: I noticed that apart from increment/decrement, static functions, switch statements and typecasts (which are easy to code around), also the & operator is not supported. I can work around by calloc'ing a buffer, writing the value there, and passing the buffer instead, but I wonder if there is an easier / more efficient way available that I'm missing? <mihi>and about the library: was there a point (I'm missing) in renaming fputs to file_print in the "standard library"? Also, I don't see the benefits of in_set. All invocations I've seen can be easily rewritten to constructs (x == 'a' || x == 'c' || x == 'd') that are neither harder to write or harder to read, and a lot easier to optimize by a decent C compiler. <mihi>that being said, I think both the code quality and the documentation of mescc-tools-seed are very good :-) <mihi>unlike the documentation quality of GNU mes (ping janneke :D) - I'm trying for some while to just get it built on Debian. I think I have the prereqs from INSTALL file installed, yet ./configure --prefix=/opt/mes && make stops with a nondescriptive error message in GNUmakefile:95... <siraben>mihi: wow those those optimizations sound great! thanks for your preliminary work! <mihi>(I once was able to build it, but then I made the mistake to "make install" it (to the default prefix of /usr/local), which messed with the tcc installed there by overwriting/shadowing some include files. Then I decided to throw away the VM and start from scratch <pder>mihi: that is great! thanks for your work <mihi>OK, when I manually remove GUILD_OPTIMIZE from config.sh, mes at least starts building <mihi>also, when tcc is in $PATH and not passing CC=gcc to ./configure, the build segfaults :-O <mihi>so, preliminary result is to try "./configure CC=gcc GUILD_OPTIMIZE= prefix=/opt/mes" and see how far it gets <xentrac>I'm not qualified to comment on whether the specific changes you've made are good tradeoffs, or to answer your questions, but I'm very glad to see you working on them! <xentrac>I think in general there's a tradeoff between extreme simplicity/auditability and performance, but that doesn't imply that the current state of things is Pareto optimal <mihi>I know there is overflow involved, but I thought overflow on unsigned types to be well-defined (and not nasal daemons) <mihi>after adding a workaround for this bug, my fasthex2_linker also compiles with mescc. But it runs even slower than hex2_linker compiled with outbuffer-enabled M2-planet <mihi>probably because the libc functions called by it do not implement output buffering either :) <mihi>janneke, on the positive side, I got it running :) <mihi>MES=guile /opt/mes/bin/mescc -L /opt/mes/lib -l c+gnu *.c -o mescc-bin *janneke is hunting down a mes-tcc arm miscompilation problem <mihi>also, backtraces from m2-planet + blood-elf look prettier than mescc ones, so to track down the bug I went back to printf debugging... <pder>I pushed another branch for blynn-compiler named marginally-m2-wip. I was able to modify virtually.hs to generate M2-Planet compatible code when outputing marginally.c. Unfortunately M2-Planet crashes when trying to compile this file. It looks like a stack overflow on recursive_output(). I suspect it is related to the tens of thousands of calls to initalize the prog array one element at <pder>You can reproduce by running make marginally.c followed by ./marginally.sh <siraben>pder: ooh getting marginally to compile would be a big improvement because the haskell syntax now becomes whitespace sensitive <siraben>auto formatting/linting tools and so on would work even better <pder>siraben: if you check out my branch, I am curious how to handle to ffi generation. <pder>I need to replace putchar(n) with fputc(n, stdout) <pder>and getchar() with fgetc(stdin) <pder>Just run make marginally.c <pder>It appears M2-Planet does not like calling prog[n] = x; tens of thousands of times in a row <stikonas>sorry, I wasn't following blynn-compiler stuff very closely. Is marginally.c supposed to be compiled into native executable, so that bin/vm is no longer required? <pder>stikonas: the virtually.hs compiler contains code that is similar to what is in vm.c however, there are some bits that are generated dynamically, such as the run() function <pder>so running virtually with marginally.hs as input outputs c code that can be compiled for the next stage <pder>I've been working on making the marginally.c output M2-Planet compatible <mihi>still builds with M2-Planet and with gcc, of course.