IRC channel logs
2026-08-28.log
back to list of logs
<matrix_bridge><Jeremiah Orians> It happens from time to time; best case is we get 1 new friend who joins us. Worst case is that only the people already here see it. <matrix_bridge><Jeremiah Orians> And I still don’t understand why every FORTH programmer thinks “hey, let us use every possible macro feature of this assembler” thus ensuring that the “assembly” is just FORTH code and hides the nature behind the code. <lanodan>Reminds me of the joke about half of common lisp, maybe macro assemblers are half of forth <matrix_bridge><Jeremiah Orians> More powerful than FORTH if one is using gas as that has a boatload of old school ITS trick features <matrix_bridge><Jeremiah Orians> As one abusing it can (with some really ugly macros) use it as a Lisp interpreter <matrix_bridge><Jeremiah Orians> But as you need a powerful C compiler to even build gas; it wasn’t pursued but it remains a hack available to anyone who wants a Lisp only bootstrap written in “Lisp” <ekaitz>the talk isn't uploaded yet is it? <matrix_bridge><Jeremiah Orians> Not that I have seen but I do look forward to seeing it <ekaitz>> When rebuilding a Guix system, Sample said, ""it's very depressing when you hit this chain of Rust compiles""; an attendee said it took them three days to build that on their Arm laptop. <matrix_bridge><Jeremiah Orians> Takes about 2 days on my Libreboot X200 as well (have to enable an 16GB swap partition for it to complete too) <ekaitz>i can build mes and tcc with mescc in less than a week (: <matrix_bridge><Jeremiah Orians> Well the slow only hurts the code, test, debug, fix loop <matrix_bridge><Jeremiah Orians> And the slowness only shows up once one starts to use lisp functionality that are implemented in lisp <matrix_bridge><Jeremiah Orians> And unwinding that would ultimately just turn mes.c into guile 2.0 <matrix_bridge><Andrius Štikonas> Well, that's a bit of guix fault for not updating mrustc <matrix_bridge><Andrius Štikonas> mrustc can build a fairly new rustc, maybe 1.91 if i recall correctly <fossy>"Arm laptop" also, which I imagine is quite non-performant <fossy>wait, but that wouldn't even use mrustc, mrustc is x64 only if i recall correctly <matrix_bridge><Andrius Štikonas> In theory mrustc should work on other arches <attila_lendvai>hi! a somewhat random note: i've added x86 and arm backends to Maru that directly generate ELF binaries. i've also rewritten the build of Maru in Maru. with that it became completely freestanding on top of the Linux kernel. <attila_lendvai>i have two ideas bugging me to work on: create a smaller Maru that has no interpreter and GC, only a JIT compiler and stack allocation. <attila_lendvai>and the other is to put together some PEG based C parser to bootstrap gcc on top of Maru <attila_lendvai>Karu -- the smaller Maru -- would be like one of those tiny Forth's but without the reverse polish mental tax <attila_lendvai>*a JIT-capable compiler. i.e. it could emit ELF binaries, and also even have a REPL that stack allocates and uses JIT <fossy>yeah, last time i tested it on arm, mrustc didn't work, but maybe fixed by now <attila_lendvai>unless i'm blind to some obstacles, it's "within reach" to put together a pretty fast Maru -> PEG -> C compiler -> gcc bootstrap. where within reach means that it's mostly "just" engineering work. <matrix_bridge><Jeremiah Orians> Well, that is certainly technically true. It is the tedious and boring bit that usually causes the thing to not exist. <matrix_bridge><Jeremiah Orians> As even going from a minimal assembler to C is quite simple and straightforward (but a good bit tedious to do) <matrix_bridge><Jeremiah Orians> (Which is what the cc_* family of C compilers are) <matrix_bridge><Jeremiah Orians> And it is that volume of tedium that creates the inertia that prevents people from making them better <matrix_bridge><Jeremiah Orians> And that slow steady pace of C that requires the team effort that produces the code that has a group that keeps slowly growing and fixing things that prevents that hard stagnation that keeps showing up when it gets good enough that the problem stops bugging you and the motivation to keep going ends. <attila_lendvai>Jeremiah Orians, but the nice thing is that there's not a lot of tedium in my (vapourware) chain. at least certainly nothing comparable to a C compiler written in asm <matrix_bridge><Jeremiah Orians> Well cc_x86 was written in 24 hours (literally in a single session) and at its core it is a trivial state machine that reads 1 list of strings (tracks variables’ offsets) and then just outputs a new list of strings. And it is the tiny bits that aren’t hard or complex but they add up to virtually all of the work. <matrix_bridge><Andrius Štikonas> Well, if yoh start with hex, there ia no way around programming higher language in assembly <matrix_bridge><Andrius Štikonas> You can understand it even without ever having studied compilers <attila_lendvai>well, it's possible to generate the asm and capture it. admittedly, it's not "fair play" in some sense. but if cc_x86 really is that simple, then my point is moot. <matrix_bridge><Jeremiah Orians> (Kinda was my goal of a good enough C to do interesting things but simple enough that it would be straightforward to understand) <attila_lendvai>i never thought too long about compiling C, but it looks impressively small! congrats! <matrix_bridge><Jeremiah Orians> I put off writing it for way too long. Then there I was; in the hospital, watching over my mom hoping for her to pull through. And just hammered away at the keyboard while listening to the beeping medical machines. And when I finally finished, she woke up and was fine 2 days later. <matrix_bridge><Jeremiah Orians> Every major milestone in stage0 kind of followed that pattern; just keep going over the idea again and again until something forces “just do it already” <matrix_bridge><Jeremiah Orians> The most clever things came from janneke and other people <matrix_bridge><Jeremiah Orians> It made me realize that I didn’t have to be clever and do everything perfectly. I just needed something good enough to perhaps give someone else an idea or a starting point or just a temporary solution that enables someone else to achieve their goals. <matrix_bridge><Jeremiah Orians> Well everything created comes from something that motivated someone to do it. So everything has an interesting story behind it <matrix_bridge><Jeremiah Orians> The problem is that as a culture, we don’t collect or share the stories <notgull>Perhaps the only C compiler to be written in a less advanced language than C <matrix_bridge><Jeremiah Orians> Turns out that a guy wrote a C compiler in assembly for DOS in the 1980s and sold it as a commercial product <matrix_bridge><Jeremiah Orians> I didn’t even find out about it until a year after I released cc_x86 <matrix_bridge><Jeremiah Orians> So one has to go with the first C compiler written in assembly for a Unix system <matrix_bridge><Jeremiah Orians> cc_x86 is an order of magnitude smaller than it and supports more functionality (but unfortunately uses a bunch more RAM to do so) <aggi>> But as you need a powerful C compiler to even build gas <aggi>so far i could confirm bin86/as86 and too YASM can be compiled with tinycc (see tiny-bootstrap/steps-tiny) <aggi>not a big achievement, but it spared me the hazzle to bootstrap all the way up to scheme/autotools/binutils, and having available an assembler for syslinux and kernel bootcode.S <aggi>from a practical perspective <aggi>availability of any assembler is a major burden still <attila_lendvai>remind me please, is it part of the ideal for a full bootstrap to avoid capturing and starting from any sources that are not hand written, or at least not readable as if it was hand written...? <matrix_bridge><Andrius Štikonas> In live-bootstrap we try to avoid pregenerated files <roconnor>My Ben Lynn-style bootstrapping of Haskell from assembly is coming along slowly but it works really well. I suspect it is a better approach than just writing something like LISP entirely in assembly, though there are clearly tradeoffs. <roconnor>You have more stages and over all more code, but the code is generally more readable, and the code in the various stages are incremental. <roconnor>s/it works really well/the approach works really well. <ekaitz>the lisp in assembly is not really just lisp in assembly but a very small set of lisp primitives in assembly and then lisp in lisp <ekaitz>same thing in C really, in GNU Mes we do have quite a bunch of things in C, but as early as we can we run from Scheme <ekaitz>i wrote a macro expander in C to begin with, but samplet (the guy un the talk before, and the Germ author) moved it to scheme <ekaitz>all the evaluator driver was also done in C, but now it's Scheme who does all that <ekaitz>we could even write the bytecode compiler in Scheme <ekaitz>that makes up a very think C (or assembly) layer, just enough to bootstrap the interpreter <matrix_bridge><Jeremiah Orians> Odd thought but why hasn’t anyone pursued a scheme to assembly compiler? And then just compile mescc into a much faster running binary? <matrix_bridge><Jeremiah Orians> It should (in theory) be much simpler than a C compiler and thus run faster <lanodan>Is the slow part of mescc really on C-specific things like C parsing? <janneke>oriansj: yeah, many interesting avenues are possible <janneke>there's scheme48's pre-scheme, and the recent guile-steel project <janneke>but those compile a limited version of scheme to C <janneke>...asumming everyone and their aunt has a C copmiler available <janneke>so, very interesting, but not directly applicable to bootstrapping <janneke>of course, mescc has an assembly backend, so it could be interesting to try to frankenstein pre-scheme/guile-steel onto the mescc backend...but yeah -- not really low hanging fruit <janneke>of course, samplet has written kind-of a scheme->assembly compiler with his germ0? <janneke>hmm, maybe i'm confusing things here, ekaitz? <matrix_bridge><Jeremiah Orians> lanodan: well compiled code always runs faster than interpreting it but it definitely depends on if it is faster to compile and then run or just interpreting once. (That is why jit interpreters exist) <lanodan>Interestingly I typically more take JIT interpreters as existing more due to native code not allowing to properly express the language constraints (or lack thereof, like with the way JS does typing, or references by dynamic names rather than pointer-like values) <ekaitz>janneke: he did write some scheme-like assembly, yes <ekaitz>lanodan: no, the slow part of mescc is probably just the mes interpreter and the macro expander <ekaitz>C contructs are hard to parse too, but there's are HUGE gains that we could achieve just improving the interpreter <ekaitz>and about compiling Scheme to assembly. It's a possibility, but I don't think it's as easy as an interpreter <ekaitz>in fact, i started one, long time ago haha