IRC channel logs

2020-10-04.log

back to list of logs

<OriansJ`>or I just incredibly stupid and missing something completely obvious
<xentrac>when programming I spend a substantial fraction of my time missing things that are, in retrospect, completely obvious
<OriansJ`>hence why I am begging janneke to take 2 minutes to get me a single guile command to work using MesCC
<OriansJ`>because I don't know what I am missing.
<OriansJ`>I just want someone to be able to git clone mes-m2; run that command (or an alternate one because I missed something there)
<OriansJ`>and demonstrate MesCC compiling anything
<OriansJ`>I don't care if it is hello world or return-42.c
<xentrac>yeah, it's always better to work with a buddy
<OriansJ`>Just something that works using only guile and the source code in mes-m2
<OriansJ`>xentrac: and what buddy is better than the original and primary author of the very program you wish to run.
<OriansJ`>am I asking too much?
<OriansJ`>I've literally done every single step from hex0 to M2-Planet + mes-m2; I just need the bare minimal MesCC that works with guile; so that I have a stable target to complete the bootstrap.
<xentrac>maybe if janneke is asleep or something then asking him to help you right now might be asking too much :)
<OriansJ`>xentrac: true; I guess I keep forgetting the distance between us all.
<xentrac>or on a fishing trip, or just sick of achieving amazing accomplishments
<OriansJ`>well he is 7 hours ahead of me if I remember correctly so 3:38am; thus probably sleeping or having a great time away from the computer.
<OriansJ`>the fact that no one else on is saying "hey idiot the solution is this: posts patch" does not look good in regards to MesCC's bus factor.
<OriansJ`>unless most of the people on the channel are just entirely passive observers and wouldn't post "I'm here but don't know how to fix that"
<xentrac>that's kindof where I'm at: passive observer of everything
<xentrac>not my intention or desire, but that's where I am at the moment. sorry
<OriansJ`>xentrac: fair but atleast you interact; otherwise I'd be effectively posting to an empty channel and wondering why even bother if no one cares to so much as communicate "meh"
<OriansJ`>Heck the net reaction of being the only person to ever write a C compiler in arm assembly was iterally 2 up votes and an email in chinese (according to google translate) telling me to kill myself because I am keeping bitcoin insecure by not working harder.
<OriansJ`>mostly I just lost all motivation to do any work for a week after I got that...
<Hagfish>maybe your chinese cyberbully should have sent you some free bitcoin to motivate you to improve bitcoin more :)
<Hagfish>i wonder if that's a technique state-sponsored hackers will adopt (if they haven't already): finding contacting details of open source contributors and spamming them with demotivating rubbish
<Hagfish>using GPT-3 they could automate that quite well
<Hagfish>*contact details
<OriansJ`>Hagfish: The only crypto donation I got was approximately $10 of Lumens from nixo; through keybase
<xentrac>OriansJ`: there are always foolish and aggressive people; after all everyone is born that way
<xentrac>what matters is the few who are not
<OriansJ`>I honestly don't do this work for anyone else; I do it because I have to get it outside of me.
<OriansJ`>but lately, playing with my son; that need isn't so bad.
<OriansJ`>now it is more like, a fun puzzle to work on in what little free time I have.
<OriansJ`>I guess, I look forward more to the hardware work; after I finish the GCC bootstrap.
<OriansJ`>Mostly, I look forward to sharing all of this with my son when he gets older.
<OriansJ`>I might end up having to write alot more explainations of various parts (maybe write a book or 2)
<OriansJ`>akin to the Lion's book
<xentrac>I really appreciate that you're doing it, for what that's worth
<OriansJ`>maybe call it "Bootstrapping GCC with rage, depression, a few friends and 50 man years of work"
<xentrac>have you read the scsh acknowledgments?
<OriansJ`>xentrac: no, I have not. Funny?
<OriansJ`> https://scsh.net/docu/html/man.html now that is impressive
<OriansJ`>makes me wish I learned that shell before bash
<xentrac>some people find it funny
<xentrac>yes, that
<OriansJ`>this one is good too: https://www.ccs.neu.edu/home/shivers/advisor-stmt-original.txt
<xentrac>it's always refreshing to see someone who so completely rejects opportunities to self-promote
<OriansJ`>well because without minimal self-promotion, nothing one does will generally be noted.
<xentrac>well, he does promote things he does, as well as things other people do, or did
<OriansJ`>xentrac: so in effect, he is an amazing self-promoter; who is capable of convincing you that he is so impressive that he can completely reject opporunities to self-promote but still get noticed.
<OriansJ`>Which reminds me of the rule of 10,000 ; imagine anything that you believe that everyone in the world knows about at this very second. Now realize that no matter what there are 10,000 new people showing up tomorrow. How do we ensure they find out too.
***OriansJ` is now known as OriansJ
<OriansJ>well let us hope 10am is janneke awake/online time
<fossy>OriansJ: which TZ are you in?
<fossy>oh, OriansJ, i might be able to help you
<fossy>this is what i am using rn for gcc-seed:
<fossy>guile --no-auto-compile -e main -L module -L mes/module module/mescc.scm -o prog prog.c
<fossy>it took me a fiddling to get that to work well, though
<OriansJ>fossy: same timezone as Detroit
<fossy>from the root of a mes tarball post-make
<fossy>happy to help you try and get further, I hope I have a reasonable understanding of how to run mescc since I struggled with guile and mes for quite a while
<OriansJ>well, let us help others avoid the struggle by getting MesCC working in mes-m2 right out of the box
<fossy>if it works i would be over the moon TBH
<fossy>i can't grok scheme atm
<fossy>i've been trying to get a hold of it but functional programming is still a bit over my head in some ways
<xentrac>OriansJ: yes, there is surely a countersignaling component to Shivers's trolling
<OriansJ>fossy: no luck thus far here for me
<g_bor[m]1> [OriansJ](https://matrix.to/#/@freenode_OriansJ:matrix.org): hope that i am not too late to the party, but I just read the tail calls discussion.
<OriansJ>g_bor[m]1: it is never too late to contribute
<OriansJ>the big piece right now is getting MesCC to work out of the box in mes-m2; just leveraging a single guile command.
<g_bor[m]1>I believe it would be manageable to create a simplified thing that does continuation passing style. It would serve as an immediate layer. Then tail calls simply get out of the equation. How does that sound?
<g_bor[m]1>Intermediate...
<OriansJ>g_bor[m]1: certainly possible
<rain1>morning
<OriansJ>morning rain1
<g_bor[m]1>morning
<OriansJ>g_bor[m]1: I just don't know a way of implementing CPS that doesn't create one big tangled mess
<rain1>i had bad luck with CPS before
<OriansJ>as you can see; I really want mes-m2 to be trivial to understand: https://github.com/oriansj/mes-m2/blob/master/mes_eval.c#L224
<rain1> https://github.com/rain-1/single_cream/blob/master/src/sch3.c#L999 this is what i did
<rain1>for calls in tail position we use goto to jump back instead of recursion
<g_bor[m]1>The thing here is that the intermediate rep does not need to be 'usable'. We can use the simplest possible transform. I would go with a mechanical cps transform on the scheme site, and yes, goto for c calls.
<rain1> https://github.com/rain-1/single_cream/blob/master/src/sch3.c#L1157 when applying a closure we set the current exp to its body and the env to its (already evaluated) arguments - and then jump back to eval
<g_bor[m]1>In tail position.
<g_bor[m]1>It does not even matter how long code it produces...
<g_bor[m]1>So it would be ok to be a tangled mess, as far as only the generated code is a tangled mess, but the transpilers are simple.
<g_bor[m]1>What do you think?
<rain1>the problem ih ad with my early compiler was that the CPS generated lots of extra lambdas
<rain1>and this slowed down execution
<rain1>of course I did something wrong
<rain1>I think I know now, how you do it right - http://matt.might.net/articles/cps-conversion/ - but i have not tried it
<rain1>so i am just a bit scared of having the same blowup problem again
<OriansJ>g_bor[m]1: really not a fan of tangled messes; as I want people to be able to audit, debug and generally understand everything about mes-m2. So that they know nothing underhanded is hidden anywhere.
<rain1>the thing about the CPS transform is technically you can just turn everything into ore lambdas
<rain1>more*
<rain1>but it's way better to classify CPS created lambdas according to their kind and execute them differently
<rain1>this is where the link talks about Partitioned CPS, recovering the stack
<g_bor[m]1> [OriansJ](https://matrix.to/#/@freenode_OriansJ:matrix.org): yes, it depeds on how you define the complexity. I was thinking about in terms of this: have a simple source, then have a chain of simple transformers. If you are confident that these are doing the right thing, it does not matter how complicated are the intermediate representations passed along the chain.
<OriansJ>g_bor[m]1: look, I am fine with complext intermediate representations (comments can easily explain them in detail); I just don't know how to get CPS into mes-m2 in a simple form.
<g_bor[m]1>There is also one more thing, in the first layer simplicity dominates over performance. As we build up the bootstrap, we can change the transformers of the chain with more performant ones, as we have more powerful tool to build these, and we might express them with similar simplicity higher up the chain.
<g_bor[m]1>Ok, that now makes sense to me.
<g_bor[m]1>I will try to have a look
<OriansJ>well g_bor[m]1, mes-m2 is well on its way to being able to run http://canonical.org/~kragen/sw/urscheme/
<OriansJ>which would allow us to move the scheme bootstrap work into a subset of scheme itself
<g_bor[m]1>Ok, will have a look at that also.
<OriansJ>The primary limitation there right now is I need to fix mes-m2's macro expansion phase: https://github.com/oriansj/mes-m2/blob/master/mes_macro.c
<OriansJ>and then instead of messing around in C; scheme can become the primary language of bootstrapping work
<rain1>yeah getting self extensible as soon as possible is the key
<OriansJ>but personally, I am hoping I can just get MesCC in a working state; so that mes-m2 will be able to grow to run it directly. So that I don't end up having to build a scheme compiler too
<rain1>you could probably cut that file down a lot, since you have eval already it isn't really necessary to implement stuff like a macro table
<rain1>since that can just be implemented in scheme
<rain1>that's what i did in single_cream
<OriansJ>rain1: you are probably right
<OriansJ>just like I could probably simplify the reader and printer too by having the scheme core lambda lift it
<rain1>the printer yeah, but doing a reader im not sure
<rain1>unless you included pre-parsed scheme code in a C file
<OriansJ>but I guess those last 2 years working in assembly, made me look at it differently
<OriansJ>looks like janneke is now online
<OriansJ>janneke: I need your help with MesCC
<janneke>OriansJ: sure, what's up
<OriansJ>I need your help getting the version of MesCC in mes-m2 working out of the box
<OriansJ>eg one should be able to run git clone and then guile --no-auto-compile -e main -L module -L mes/module -s module/mescc.scm -c mes.c -o foo.S and see MesCC produce a useful result
<OriansJ>if you could build off of commit 383436c07a4f86fad6218ea2bef285229a7c6ad5 it would be quite helpful
<OriansJ>or guile -L module/ -e main -s scripts/mescc.scm -- -c mes.c -o foo.S (basically any single guile command which would result in MesCC compiling anything)
*janneke pulls
<janneke>OriansJ: alright, i'm having a look
<OriansJ>thank you janneke
<janneke>(surely you'll have to do some sort of guix environment -l guix.scm // apt install ...)
<janneke>i'm guessing something like guix environment --ad-hoc guile nyacc mescc-tools
<OriansJ>janneke: no; there will just git clone mes-m2 and then do useful work. Hence why nyacc is included in it
<janneke>ah yes, i see
<OriansJ>imagine just a statically compiled guile binary and the clone repo of mes-m2 are the only things you have on the system.
<OriansJ>as that is what mes-m2 will ultimately behave like
<stikonas>yeah, it's much easier to build with M-2 Planet than mescc, messc should also be this simple...
<janneke>hmm, guile.scm is missing
<janneke>ice-9/boot-9.scm:3300:6: In procedure resolve-interface:
<janneke>no code for module (mes guile)
<janneke>i guess that was removed/not imported either to avoid, or because we did not want, to use guile
<OriansJ>entirely possible, it would certainly be my mistake
<janneke>note that it's a good idea to compile the scm files during development
<janneke>it gives much better error messages
<OriansJ>I blame 2 years of working in hex and assembly
<janneke>hehe
<OriansJ>arm assembly is like bath salts; it only drives you crazy and you still hate the experience because instead of doing something sane like LOAD R0 #577; you have to do load R0 , [PC + 8]; b pc+4; .word 577
<OriansJ>So 12bytes to encode what could be done in 6bytes in a sane architecture
<OriansJ>it is freaking 2020, we have billions of transistors and they can't bother to support division? Seriously WTF
<OriansJ>Trying to write kaem in M1 for armv7l is an exercise in frustration.
<janneke>OriansJ: i've added two commits to master at https://gitlab.com/janneke/mes-m2
<janneke>OriansJ: hope that helps
<OriansJ>thank you janneke
<janneke>OriansJ: yw!
<jelle>TIL about GCC 2.96, somewhat bootstrapping related I guess https://twitter.com/Foone/status/1312451205814128640
<bauen1>OriansJ: i've been disassembling the boot rom of the allwinner h5 (armv7) and while the load immediate is a bit annoying everything else is pretty easy to understand (it has a certain similiarity with 6502)
<OriansJ>success
<bauen1>it does have its fair share of "obscure" opcodes
<janneke>jelle: fun times
<bauen1>there's also been another post on hackernews about a small c compiler https://news.ycombinator.com/item?id=24676851
<bauen1>apparently by the creator of 8cc but with the goal of being easier to understand
<bauen1>OriansJ: are you at the point where mescc works correctly (using guile) but mes-m2 doesn't (yet) support all features necessary to run it ?
<OriansJ>bauen1: well janneke's recent commit does get guile --no-auto-compile -L module -e main scripts/mescc.scm -S -o foo.S scaffold/exit-42.c working
<OriansJ>however guile --no-auto-compile -L module -e main scripts/mescc.scm -S mes.c -o foo.S doesn't work but I am guessing because I need to include some libraries in include and the pass a parameter to tell MesCC to use that folder instead of trying to read ~/.guix-profile/include/gnu/stubs.h:7
<janneke>yeah, -I <somewhere>; although mescc works best with mes lib c
<OriansJ>janneke: I copied over the include folder from mes (and pushed as commit 99842b12108319e8d3d4fbe9eb7c01dcaad8f206 ) yet still a bit of an error when I run: guile --no-auto-compile -L module -e main scripts/mescc.scm -I include -S mes.c -o foo.S
*janneke looks
<janneke>init-declr->info: not supported: ((ftn-declr (scope (ident "FUNCTION")) ...
<OriansJ>if you notice gcc_req.h
<OriansJ>where I typedef FUNCTION to enable a common function pointer type with GCC and M2-Planet
<OriansJ>would I be leveraging functionality that MesCC doesn't currently support?
<janneke>yes, looks like an unspported C construct
<OriansJ>but I am happy to report guile --no-auto-compile -L module -e main scripts/mescc.scm -I include -S ../mescc-tools/M1-macro.c -o foo.S works quite happily
<janneke>good!
<OriansJ>I guess I have a feature request for MesCC janneke so that it'll be able to build mes-m2
<OriansJ>^_^
<janneke>hehe, you're doing cwazy stuff that even tcc doesn't need
<janneke>you can probably #ifdef around that for now
<OriansJ>yet so trivial to support https://github.com/oriansj/M2-Planet/blob/master/cc_core.c#L352
<OriansJ>well I am dreaming of a day where we no longer need TCC and can just use MesCC to compile GCC directly.
<OriansJ>I guess I finally beat janneke to supporting a C feature. It took 2 years but I finally did it ^_^
<janneke>:)
<OriansJ>had to go crazy in assembly and bootstrap the world from scratch but finally after 2 long years. I finally didn't get beaten to a C feature by janneke ^_^
<OriansJ>now I have the irony of having the ability to bootstrap mes-m2 but not the ability to run MesCC on mes-m2; which can bootstrap GCC but not mes-m2.
<janneke>brilliant!
<OriansJ>So I guess it is now a race to see which happens first. MesCC gaining the ability to build mes-m2 or mes-m2 gaining the ability to run MesCC
<OriansJ>This seriously is HILARIOUS, I gotta put this in the README
<rain1>haha
<OriansJ>now for the entire world to see: https://github.com/oriansj/mes-m2/blob/master/README.md
<bauen1>lol
<OriansJ>I guess the biggest bootstrapping challenge of all has just started. Is janneke able to build a C compiler powerful enough to build the crap that I write. ^_^
<bauen1>and this is the last components missing to bootstrapping linux + gnu from nothing
<OriansJ>bauen1: effectively yes
*janneke gives up
<OriansJ>LOLZ
<janneke>let's call it kwits
<bauen1>awesome
<OriansJ>*ROFL*
<janneke>that proves it, -can't be done-
<OriansJ>*shit you made me laugh so loud I woke up my son and my wife is pissed*
<janneke>hehe, *lol* -- oops
<janneke>you can tell her i apologized
<janneke>(at a good time)
<OriansJ>from the other side of the house no less
<OriansJ>and now here I am wondering, does this explain all of the insanity I saw in Mes.c
<OriansJ>like janneke forgot that function pointers existed and reinvented a new type of function pointers to shoe horn that functionality into mes.c
<OriansJ>oh my god, it explains SOOO MUCH
<OriansJ>janneke literally void*'d his way to bootstrap GCC
<OriansJ>So we have a scheme programmer dealing mostly with C and a C programmer dealing mostly with scheme.
<janneke>oh my, looks like i've been silly :-)
<janneke>oh well, easy cleanups are the best
<OriansJ>I think I know how to fix macros in mes-m2 now
<Hagfish>from the creator of 8cc: https://github.com/rui314/chibicc
<Hagfish>(another small C compiler that can't compile gcc?)
<stikonas>maybe nobody tried?
<OriansJ>Hagfish: well it is trivial to create a C compiler
<OriansJ>and if someone took the time to simplify GCC, then most C compilers in the world would be able to compile GCC with trivial efforts
<OriansJ>but as no one is crazy enough to do that, we are stuck with only equally crazy efforts for making compilers capable of building the current mess that is GCC.
<OriansJ>It would take 2 years of effort but it isn't outside the realm of possiblity that someone could convert GCC 4.7.4 into a form that M2-Planet could directly compile.
<OriansJ>Honestly, I toyed with the idea of doing that mightself for the M3 work.
<OriansJ>then I saw the state of binutils.
<OriansJ>having to support all of that arbitrary half supported crap for platforms that don't even exist anymore (Itanic anyone?) and binary formats no one uses (BeOS hunk) simply because no one has the "authority" to remove anything.
<OriansJ>but silently breaking functionality and leaving a boatload of compiler warning around like a river of sewage through a school playground
<OriansJ>if anything the source code for compilers by definition must be the cleanest code on the block but the reality one sees in clang and GCC reminds one of cthulhu and the filth of eldrich horror; which comes as a side effect of people working in a code base levels beyound their understanding.
<OriansJ>I guess one could say the best thing about C compilers is there are so many standards to choose from and only a handful of complex programs work with multiple C compilers.
<OriansJ>Which is why GCC is so hard to replace with Clang, despite literal armies of paid programmers trying to replace the need for GCC.
<OriansJ>At its core, C is a trivial language. you take a stream of characters and convert into a list of tokens. you feed that list of tokens into a C state machine and out comes the assembly list. Which you then can optimize to various levels and then you convert the remaining assembly list into an object file; that you then link into your binary.
<OriansJ>depending upon how much of the language you wish to support, it can be done in less than 500 lines of C code.
<OriansJ>with the C state machine being either the simplest or the most complex part of your program. (With optimzation either being missing or the most complex part of your program)
<OriansJ>and yes the preprocessor can really complicate the shit out of everything but it probably should be thought of as a seperate program.
<V>a very simple unoptimised compiler, yes
<V>you *probably* want to lower it to an IR, then have a large number of optimisation passes on that, along with keeping metadata attached so you can do LTO...
<V>and that's not to mention the amount of effort it takes to write a parser that can recover from syntax errors, good error messages, static analysis for dead code & memory unsafety, ...
<V>and then generating code that's properly optimised for n different architectures, where different operations become more efficient over time, etc
<bauen1>the preprocessor should really be a standalone program, but at the same time it really shouldn't exist (in it's current form)
<V>*also* if you want to be compatible with vendor-specific extensions (which are real and useful to a decent extent) then there's all of that as well
<OriansJ>V: indeed making C fast or easy to work with is a bitch to do
<OriansJ>but then again so is every other serious language
<OriansJ>basic lisp interpreter -> 300 lines of C; A full compliant scheme -> 177,056 lines of C and 92,817 lines of scheme too
<OriansJ>but that might just be me complaining about how much of that standard, I have to support to build other people's shit.
***ChanServ sets mode: +o rekado