IRC channel logs
2020-12-02.log
back to list of logs
<pder>Oriansj: I pushed one more change that I believe fixes the lonely.c differences <pder>Yes b4143cf4a4c982 should fix the lonely.c differences. Its also an example of a workaround for the FUNCTION problem. <OriansJ>pder: I'll look deeper to see if I can figure out the reason <OriansJ>Either locals in M2-Planet are broken in some deep fundational way or we are missing something <OriansJ>also pder there is no FUNCTION pointers in your commit; so it isn't a problem with that. Nor by looking at the assembly that it has to do with the function call at all; unless fgetc is screwing up the stack somehow but I am looking into that too. <OriansJ>but yet somehow it looks like locals are off by 4 <OriansJ>except when I try to debug then they both segfault <pder>oriansj: in that commit the function io_get is passed to run(FUNCTION get, FUNCTION put) so I thought it might be related to that <siraben>pder: thanks a lot for your work! I guess the pressure's on me now to write that Scheme, heh <OriansJ>pder: I think it still has to do with locals in M2-Planet but I haven't been able to work out a good solution to it yet <OriansJ>maybe I just need to byte the bullet and eliminate the push/pop entirely for locals <OriansJ>but I'll look more at that tomorrow. Good night. <OriansJ>ok when a function call is made in M2-Planet to a function which takes no arguments; esp and ebp should be exactly 4 different (The size of the return address for RET) <OriansJ>FUNCTION_ioget starts with the wrong ebp <OriansJ>why because the function run is doing get(0); <OriansJ>So M2-Planet is generating the correct local behavior but the code is passing an argument to a function that doesn't accept an argument and throwing things off. <OriansJ>The problem is we should be throwing a big fat error when calling a function that doesn't accept arguments and trying to pass it arguments. <OriansJ>and it applies to the other cases as well <OriansJ>and it found another place where there is a problem ioccc_get <OriansJ>why GCC/Clang doesn't atleast show a warning for this sort of thing is beyound me (possibly to improve compile benchmark times?) <OriansJ>I'll have the patch up once I finish triple checking that it is doing what is expected. <OriansJ>although I really don't like the while((c = str_get(0))) and will probably have to figure out a better solution for that. <OriansJ>and as we go, I'll probably have to make some bigger changes so that vm.c becomes something we can properly fuzz <fossy>pder: i can confirm that ./vm run > raw worked for me as well when compiled by M2-Planet <fossy>however ./vm run dosen't work at all, even for the most simple haskell program given in the README <OriansJ>fossy: checkout out my latest commit; it properly generates generated/lonely.c <fossy>rts.c would need to be converted to M2-Planet tho to fix the TODO right <OriansJ>fossy: yep and we have the question of how to deal with the big fat static const u prog[]={81,37,81,... <OriansJ>fossy: M2-Planet doesn't yet support the ability to do char c[]= {1,2,3...}; yet <fossy>should be possible to do a translation layer, no? <OriansJ>fossy: just haven't figured out the correct answer yet <fossy>those number code programs get super long, iirc <OriansJ>but fixing rts.c should give us a better idea of a proper solution <fossy>i think for precisely it was close to 1m characters in the struct <OriansJ>I'm not exactly a fan of magic numbers <fossy>its pretty much what this whole project rests on, no? <OriansJ>until I find a better way to express it <OriansJ>unpacking the magic will ultimately have to happen <OriansJ>and I get the sneaking feeling that rts.c is just a slightly extended version of vm.c's state machine and the blob is just there to play the role of the blobs in vm.c <OriansJ>in which case, me exploding vm.c to a simpler form will eliminate the need for rts.c entirely and cut the number of compile steps considerably. <Hagfish>exciting stuff, and great work everyone :) <pder>orianj: great find. thanks for looking into that. I am wondering if functions like io_get could still be declared with no parameters and then simply call them with get() instead of get(0)? <siraben>OriansJ: i can adjust the Haskell output <janneke>dorion: that's interesting; the GNU Mes bootstrap is being developed on Guix, a port to NixOS is underway <siraben>Yeah, I hope NixOS can benefit from this as well <V>Nixpkgs contains a lot of binary packages... <xentrac>I see I failed to wish everyone happy AIM-349 day yesterday <xentrac>so today Scheme is 45 years and one day ld <OriansJ>pder: yes we could do that easily in M2-Planet; the problem is GCC doesn't support universal function pointers and instead is limited to the forms like: typedef unsigned (*FUNCTION) (unsigned); which does include more type information than just naked function pointers <OriansJ>I'm also going to probably make some changes in run which would remove the need for the GET function pointer being passed. <OriansJ>dorion: I personally use Debian and Guix but if I wanted a minimal bootstrap distro; I'd just use guile as the init; add in gash, gash-utils, MesCC and slow-utils and you have a single binary system; able to build and bootstrap anything else you want. (although slow-utils kind of got left in the dust and could use someone else to take over its responsibility) <OriansJ>[as it is mescc-tools written in scheme] <OriansJ>deesix did alot of good work for it (That I seem to have lost ;_; ) <fossy>guile is too large for my liking, my (new) plan for such a thing is basically a kernel in m2-planet and a kaem init <OriansJ>fossy: fair; mes-m2 might only be 233,839bytes in size when built via M2-Planet but it still needs alot more love before it could even be considered fit for purpose. and guile statically built with GCC is big <fossy>And then there is the precompiled modules <siraben>oh yeah, especially the unfree stuff <V>siraben: not just the unfree stuff <siraben>You could disable the cache and build everything from source <V>bunch of packages I recall there not being a bootstrap path for, just using vendor-provided binaries <V>I'm not even talking about the cache here <siraben>Does Guix build everything from source? <vagrantc>oh, and there are a few other bootstrap binaries for... haskell maybe? <siraben>Establishing a clear bootstrap path for packages would be good for Nix <janneke>siraben: the core nix bootstrap isn't too bad <siraben>I've cross-compiled Nix itself for a different target <Darius>belated happy scheme day, i didn't know <Darius>we really must plan something special for the half-century mark <siraben>preserves the license headers but makes it more readable on GitHub <janneke>siraben: i'm not familiar myself with the nix bootstrap, but i'm told it has no cycles <janneke>ignoring all other (non core-c) binary roots <fossy>Im trying to bring non binary bootstrapps to void for a whole ton of languages <fossy>if they dont accept it, I think ill just fork to an extent <fossy>OriansJ: in M1, how would you create 16 bit code? (I.e. for x86 16 bit mode) <pabs3>which other languages are you working on?