IRC channel logs
2020-11-15.log
back to list of logs
<siraben>OriansJ: Got a reply. He would be happy to license it under GPLv3. <OriansJ>the first steps are likely put vm.c into something M2-Planet can compile. <fossy>i do not believe that will be hard <OriansJ>well the enums we can replace with constants <OriansJ>siraben: yes but not typedef; so those will need to be expanded <fossy>the main things it dosen't have is switch, static, inline that vm.c uses <OriansJ>M2-Planet will tell you when it hits something it doesn't understand <siraben>What about `void loadRaw(u (*get)())` <siraben>Ok, so the `run` function would look a bit different because of lack of switch <OriansJ>it would be written as void loadRaw(FUNCTION get) <fossy>OriansJ: does it support ternary operator? <fossy>i don't remember that one either <OriansJ>fossy: not officially in C but if you look in M2-Planet's gcc_req.h how it can be made compatible <siraben>However the readable source is in the comments, so someone motivated enough could hand-compile <fossy>siraben: isn't hand-compiling the option given by blynn in his docs, iirc? <OriansJ>fossy: if you mean bool ? a : b; no just convert to if statement <fossy>OriansJ: yeah that's what i meant, that's scattered through vm.c as well <fossy>siraben: i believe that is fine as long as mescc-tools-seed/gcc-seed/whatever else appropriatly informs the user that they should do this <fossy>and validate the results match up <fossy>alternatively, we can write a compiler for that in M2-Planet, but I don't think it's very beneficial at the moment, especially given the (relative) ease of hand-compilation <OriansJ>well it looks like vm.c is a sort of haskell version of Lisp's SECD <siraben>Ok. Also only certain combinators perform side effects, so a term such as `BCT` is completely pure. <siraben>Looks like vm.c has multiline strings too <OriansJ>fossy: hand compile with a shitload of comments as it looks like it is object code <fossy>OriansJ: yes, someone should essentially write up the steps of hand compiling it <OriansJ>assuming the VM supports comments in its input files <OriansJ>otherwise we might need to hack it in <fossy>OriansJ: well, the sk for everything to a haskell compiler is in vm.c <fossy>then after that it's all haskell <fossy>"We have upgraded our previous parser to support comments, whitespace, and variables consisting of lowercase letters." <OriansJ>and the default make is broken in terms of dependency chain but easy to fix. <fossy>so just all: precisely should be fine <OriansJ>(as git clone, followed by make doesn't result in anything but an error) <fossy>idk why it hardcodes clang -O3 in there either <OriansJ>also seems to not pay attention to where it builds things either <siraben>without optimization enabled it runs much slower <siraben>Looks like it uses malloc for the heap, but we could use a static buffer right? `mem = malloc(TOP * sizeof(u)); altmem = malloc(TOP * sizeof(u));` <OriansJ>needs to be updated to put binaries in bin, so that it'll be easier to do make install later on <OriansJ>siraben: malloc and calloc work perfectly (free however is a nop) <OriansJ>M2-Planet also treats # as a line comment and drops //; so that it becomes trivial to mix #defines and //CONSTANT statements <OriansJ>also all of the files need proper GPLv3 license headers with correct copyright dates with authorship given to Avatar <fossy>the stages before that have to be chnaged to generate m2-planet compatible c <siraben>Ah no problem because it generates ION assembly <OriansJ>but before we get too far down the road; get proper license headers into all of the files <OriansJ>use the commit year of the files and credit Ben Lynn as the author <OriansJ>make it a pull request so that he doesn't have to do the work <OriansJ>Fix up the make file, so that new people can just do make {clean,test,all} and get the desired working results <OriansJ>then after he merges all that; we can start going after vm.c <siraben>Sounds good, glad to see you guys are on board with using his work :) <OriansJ>I'll probably have to add some time primitives to M2-Planet's library set but that is something we can stub around until I do it right and have deesix help me get it working on AArch64 as well <siraben>OriansJ: did you see the proposed bootstrapping phases I wrote? <OriansJ>siraben: not yet; as I was waiting until after the proper license incase we needed to do a clean room implementation. <OriansJ>the individual license headers is just GNU standard practice to reduce future license confusion issues. <OriansJ>plus the rewriting of vm.c into M2-Planet will give us a great chance to make it as clean and easy to understand as possible. <OriansJ>and perhaps even speed up the primitives a bit <fossy>We can try but by the looks of it ben Lynn optimized the hell out of it by the docs on his website <OriansJ>fossy: nothing teaches you more about slow C than a bad C compiler <OriansJ>worst case, we just make it cleaner. <OriansJ>and much more structured and documented <siraben>It wouldn't be too difficult to translate this into assembly as well <OriansJ>I'll take a crack at vm.c tomorrow; hopefully it doesn't take too much to get it working in M2-Planet. I leave the header and make work to anyone who wants to get it done tonight. <siraben>Sounds good. I can do the header work. <OriansJ>blynn-compiler sound like a proper program name for the license header? <OriansJ>just replace the Mes with what name you think appropriate and remove the or later bit of the license as we haven't gotten his approval for that <OriansJ>good night everyone. look forward to the changes <fossy>OriansJ: well it looks significantly easier than (say) mes or tcc, lol <fossy>siraben: wont we need to adjust lonely and some others to produce m2-compilable c <siraben>fossy: This is if we wanted to port his Haskell bootstrap completely. I'm targeting the earlier stages that generate ION assembly. <siraben>I'll draft up another possible bootstrapping plan to MES that might be easier, actually. <fossy>do you mind making a .dot or some visual that would show how we would get from m2-planet to tcc or mes or gcc or whatever we currently have? <siraben>Ah, I have it written down, let me send <siraben>So where would this fit? Between mescc and mescc? <OriansJ>depends on if you plan on using mes-m2 or just M2-Planet <OriansJ>as writing a scheme that MesCC can run upon was the goal of mes-m2 <OriansJ>and vm.c would depend entirely on M2-Planet <OriansJ>it also looks like we could seperate the tests from the vm.c as well <OriansJ>interesting the typedef unsigned u; hid a warning when compiling with gcc. <OriansJ>weird duplication of functions with the same contents but different names <siraben>OriansJ: So it bridges M2-planet and mescc? <siraben>I see you found my commit where I added license headers, haha <OriansJ>as M2-Planet can be bootstrapped from nothing and MesCC can bootstrap GCC <OriansJ>the big problem there is mes.c includes C features that M2-Planet doesn't support and it was hard to debug. <OriansJ>I spent 6months trying to get mes.c into a shape that could be built via M2-Planet before I gave up and started trying to expand a lisp that M2-Planet could build into one that could run MesCC <OriansJ>Then I had a kid and development effort kinda took a bit of a hit <OriansJ>no one really worked on either the more M2-Planet friendly mes.c nor mes-m2 while I was out <OriansJ>as MesCC was having trouble porting to new architectures, I started on https://github.com/oriansj/M3-meteoroid to enable janneke to go to using binutils instead of mescc-tools; as The M3 series would be drop in compatibles for binutils' loader and assembler <OriansJ>I just haven't had time to finish it yet <OriansJ>Perhaps I made things too complicated and no one could figure out my mess and I should have spent more time making mes-m2 and mes.c easier to understand. <OriansJ>ok and with the latest commit, it is now having a single standard FUNCTION pointer type <siraben>updated to see how blynn-compiler fits in <OriansJ>siraben: yes; simply cc vm.c -o vm && ./vm >| raw && sha256sum raw <OriansJ>prior to any of my changes the output was 9732a8852bf92b4097f275da4ceba3b718138a5e16190cbef43bbd4be42a27dd and it still is that output <OriansJ>I'd figure blynn-compiler depends upon both M2-Planet and mes-m2 and would be used to build a scheme; which gash and MesCC would run upon. <siraben>How does M2-Planet differ from mes-m2? <OriansJ>unless our goal is to compile MesCC into a binary that runs natively <OriansJ>siraben: M2-Planet is a C compiler; mes-m2 is a scheme written in the C subset that M2-Planet supports <siraben>Ah so I should add an array from blynn-compiler to M2-Planet <OriansJ>as vm.c would need to be built by M2-Planet in order to exist in the bootstrap <OriansJ>that is probably approximately correct (depending on the scheme that comes out of blynn-compiler) <siraben>It might be more nuanced with an intermediate Scheme. It's looking like it'd be easiest to write a Scheme interpreter to be compiled with blynn-compiler <siraben>Simply because I can compile the code with GHC, test and lint it. <OriansJ>well everything put through M2-Planet can also be put through GCC for testing and linting <OriansJ>but you are right, it'll probably be easier to write a scheme in Haskell than C <siraben>Right. The second plan I was thinking about was having intermediate Lisp dialects on the way to Scheme but that'd be harder to test with external tools. <OriansJ>Ideally we could find a proper scheme in Haskell and just convert it to the subset supported by blynn-compiler <siraben>Well it doesn't have IO but it should be relatively easy to add IO, especially since blynn-compiller has do-notation <OriansJ>the Hygienic macro expansion will be the hard part <siraben>Yes, I've mentioned that a few times and it's a little scary to be honest. <siraben>Doesn't need to be the linear time hygienic expansion either, the Kohlbecker algorithm (quadratic running time worst case) suffices. <OriansJ>siraben: well syntax-case is the biggest bootstrapping problem in scheme right now <OriansJ>guile cheats using psyntax.pp and all the rest just leverage another lisp to provide syntax-case to implement syntax-case <OriansJ>even if we have to go to Haskell to get it done correctly; it'll be a huge win <siraben>My R5RS scheme interpreter manages to interpret that interpreter <OriansJ>well; we can prove how close it is using ghc to build and see if MesCC runs on it (the method of testing is in mes-m2's README) <OriansJ>and iterate on both sides of blynn-compiler; me working up via vm.c and you working down to get your scheme working from it <OriansJ>now I am just slowly chipping away at incompatibilities between M2-Planet and vm.c (and testing frequently to ensure I didn't break it) <OriansJ>and once I finish building its additional dependencies; I'll clean up the makefile so that it behaves better. <siraben>Amazing. So you think it's a pretty viable path? <OriansJ>siraben: well vm.c doesn't look too bad; so it should be a relatively easy conversion. <OriansJ>after that however; needs work to be something people can easily review and trust. <OriansJ>but working and just needs cleanup is easier than not working <OriansJ>and I just pulled out all of the switch statements <OriansJ>now to go after the ++ and -- expressions <OriansJ>but single ste[pping the code suggests otherwise <OriansJ>but throwing a & 0xFF; should get them back into matching behavior <OriansJ>Now to figure out the pointer arithmetic to ensure it doesn't cause problems for M2-Planet <samueldr>hi, I've been trying to get tinycc from jann//eke's fork to build using mescc; are there known-good pairs of mescc+that fork for x86_64? <samueldr>I need to undo some of the exploration work I've done and re-build using mes 0.21, to give you the error, it's with i386-asm.c though <janneke>samueldr: x86_64 isn't supported yet, please use the x86 variant on systems 64bits too <samueldr>aw, it wasn't exactly obvious with the docs what the status is :) <samueldr>I was hopeful that with the existing changes for x86_64 things would work <samueldr>at least mes (with 0.21) all tests pass for x86_64 <janneke>well yeah, that's my hope too, i haven't seen it working yet, though <janneke>samueldr: beware, some tests are set to XFAIL on x86_64 <samueldr>I also was hopeful that these were known to fail, but not needed for tinycc :) <samueldr>is there a document somewhere with the status on different platforms? <janneke>current states: only x86 is supported <samueldr>would be nice too to add the last known tested commits for the important dependencies (I guess mescc-tools, mes and tinycc fork) <janneke>yes; i haven't tested beyond that which is in the guix bootstrap now <samueldr>yeah, I should have said that I found the upstream commencement.scm (and bootstrap.scm) <samueldr>though I wondered too if there was a WIP version elsewhere <janneke>no, this is the latest version (at least that i know of :) <samueldr>good to know, though it feels odd how the other parts are being developed in total detachment to a more "complete" integration like that <samueldr>but eh, who am I to judge how others develop stuff? <OriansJ>mescc-tools is generally compatible with MesCC by default (The only catch is certain versions of blood-elf require slightly different elf.hex2 headers) <samueldr>OriansJ: I would guess that it doesn't have any better x86_64 support (understandbly so) <samueldr>that's likely to be the main problem with my testing :) <samueldr>finally got back to the failure (while doing other things) <samueldr>i386-asm.s:4419 :Received invalid other; mov____(%rax),%si <samueldr>mescc: failed: M1 --LittleEndian --architecture amd64 -f /nix/store/dbfryyh57ajzb2603xx1f9qgrq416my1-mes-boot-0.21/lib/x86_64-mes/x86_64.M1 -f i386-asm.s -o i386-asm.o <OriansJ>samueldr: well x86 can be used to build AMD64 on AMD64 targets; as TCC supports AMD64 if I remember correctly <samueldr>yeah, I'll now be restarting my work with x86 instead of amd64, now that I know it's not expected to work right now <janneke>samueldr: eh, you're mixing architectures <samueldr>well, the bootstrap scripts are, I would guess <samueldr>that was something I was wondering, if i386-asm was expected to be built for x86_64 <OriansJ>samueldr: the invalid other means that the file i386-asm.s contains an assembly primitive that isn't defined in x86_64.M1 <samueldr>thanks for the pointer, edited bootstrap.sh <OriansJ>samueldr: well --architecture is just how the pointers are handled; <OriansJ>and the contents of the elf.hex2 determines how the ELF file is treated by linux (as a native x86 or native AMD64 binary) 
