IRC channel logs
2019-10-22.log
back to list of logs
<OriansJ>try "kaem --verbose --strict" on mes-m2 -_^ <OriansJ>we still have to fix the struct scm* x = y+1; and struct scm* x = y+i; behaviors since +1 means 1 byte in M2-Planet and +1 means 1 sizeof(type) in C <OriansJ>which is why mes.h has CELL_SIZE defined appropriately to allow the solution to that problem <janneke>i was wondering to learn M2-Planet to eating/discarding `const' <janneke>so that mes can more easily keep using the C library alphabet <OriansJ>janneke: well getting M2-Planet to just eat const is rather simple; simply att that logic to the struct type* type_name() function in cc_types.c <OriansJ>janneke: at the same time, mes-m2 is just a bare-minimium; that is just enough for MesCC to self-host mes.c <OriansJ>honestly, built via M2-Planet it is just a 197,002byte binary that segfault when the reader works with hashes <OriansJ>A static binary with ZERO dependencies (save for a handful of syscalls) <OriansJ>if you do kaem --verbose --strict and then ./bin/mes-m2 --boot test/test000/exit.scm you'll see it loads and runs, until an interacting with the hash functionality causes it to break <OriansJ>(notice that //fd_print(..); works in M2-Planet but is ignored by gcc) <OriansJ>So what I am going to do is remove vectors and hashes as being part of the core to reduce the number of places that can cause problems (as we know M2-Planet deals with objects, strings and pointers with ease) <janneke>bash: ./kaem.run: /bin/bash: bad interpreter: No such file or directory -- haha ;) <janneke>ah, kaem --verbose --strict ... cool! <janneke>OriansJ: i am inspired to experimenting with guile primitives needed to load psyntax: letrec and module-define!, module-variable etc <janneke>however, i am postponing that to work towards a merge with mes-m2, or at least i want mes to be as close to mes-m2 as possible before adding/changing functionality <janneke>it is very possible/probable that we will have two mes'es for some time to come, but i want to maximize the chances of convergence, and better sooner than later <janneke>OriansJ: just so that you know...to get mes.c to run for the first time, i used a stepwise implementation using scaffold/micro-mes, scaffold/tiny-mes, scaffold/cons-mes <janneke>you/we could just do that for m2-planet, if that helps <janneke>probably that's more a janneke's approach, feel free to ignore! :) <OriansJ>well, as we move forward mes-m2 is going to become more like mes.c <OriansJ>janneke: and with very little work, we can make it a drop in compatbile for mes.c <OriansJ>and by simplifying the internals and focusing on doing things in a cleaner manner, major performance enhancments can be done efficiently. <OriansJ>and if you notice how fast the build is <OriansJ>both with gcc and M2-Planet; you gain the ability to quickly iterate changes and know that the build doesn't break <janneke>yes, i added a similar simple.make to mes on the wip-m2 branch <OriansJ>janneke: hopefully the constraints demonstrated in mes-m2 are reasonable for you to work with <janneke>OriansJ: it is so inspiring to see that we are almost there <janneke>my first wip-m2 branch is from over a year ago <janneke>many things did not seem feasible ... now it links, runs and segfaults! <stikonas>Hopefully, sorting out those hashes won't be too difficult <OriansJ>stikonas: it is just a sort of a one by one sort of problem <OriansJ>it is why ultimately I am going to make mes-m2 hash-free as it will make the code simpler and easier to understand <OriansJ>janneke: plus mes-m2 has the largest amount of gotos ever tested in M2-Planet <OriansJ>hopefully, there isn't C stack growing constructs inside of the gotos; as that could easily cause a stackoverflow <OriansJ>plus since the GCC and M2-Planet work can happen in parallel; now is the time to get people working on making mes-m2 as guile compatible as possible so we can port guix to it <janneke>OriansJ: on my mes wip-m2 branch, i now have a #define switch: POINTER_CELLS <janneke>that switches the some initializations and and disables the garbage collector <janneke>it now starts to pass quite some tests, same code for number-based/pointer based cells <janneke>i also have a script pointer.sh, that removes almost all remaining macros <OriansJ>I probably need to put a garbage collector back in eventually <janneke>tomorrow i will have a look at the garbage collector <OriansJ>but I figure solving the hash/vector bit probably is a bigger priority in getting mes-m2 able to build something more impressive <janneke>OriansJ: does M2-Planet have `long' or unsigned? <janneke>i find the pointer based cells still kinda scary <OriansJ>janneke: also everything in M2-Planet is currently unsigned <OriansJ>well if you look at cc_types.c, you'll see it is architecture specific <OriansJ>essentially it is either whole register or byte manipulation <OriansJ>which honestly is all one needs to write a solid C compiler <janneke>oh, it should be trivial to add size_t and ssize_t too (not conforming signedness, but to stay with the c header alphabet) <OriansJ>janneke: that is the idea, it is trivial to add support for anything you want in M2-Planet <OriansJ>I mean honestly, by simply expanding the type system to be more complete and expanding the logic to subtly change behavior when handling various types, one could in theory compile TCC by simply slowly bolting on more features... <janneke>wow, so much progress the past week... <OriansJ>one could even use M2-Planet to write a simple C macro expander to make M2-Planet much more C compatible if one wanted