IRC channel logs

<FransFaase>I have made some changes to pass1.kaem of the tcc-0.9.27 step and now it compiles with tcc-0.9.26 for x86_64/amd64 and arm64/AArch64. Is it worth the effort to trying to port it to live-bootstrap and make a pull request? It does need some patches and also some additional files to be able to compile for arm64.

<jackdk>Kicking out the GNU build system? Interesting - I still use it when I plan "bootstrappable" projects where I don't otherwise need C++ or Python, because CMake and Meson bring in too much and I don't want to write raw makefiles that follow the standard targets

<jackdk>I know you're thinking of system bootstrap stuff, whereas I'm thinking of bootstrapping larger software on top of a bootstrapped system.

<lanodan>Well for meson there's https://muon.build/ which brings much less dependencies while having really nice compatibility

<jackdk>I found it not quite compatible enough, and I don't like Meson's "here is the finite universe of compilers that I care about" model. Also the fact that the meson CLI "owns" commands that IMHO belong to the build runner (ninja/samu) rubs me the wrong way

<aggi>i'm just become a little mad, from the system-integration perspective

<aggi>GNU buildsystem in practice, isn't the worst choice by far, in particular when software is properly maintained

<aggi>including cross-compilation, static linking, header sanity etc.

<aggi>it's the whole infrastructure surrounding entire GNU toolchain

<aggi>in this regard tinycc, for example, was much easier to cope with

<aggi>it is cross-compiled including all it's cross-compilers in a few minutes

<aggi>in comparison GNU toolchain needs hours and days plus all the preceeding bootstrapping steps

<aggi>a recent favorite of mine concerning build system isn't a GNU one besides

<aggi>seeking to integrate cdrtools into live-bootstrap configurator/steps system

<aggi>then recently, german government passed a 500billion "special budget" here, with promises some of this money was dedicated

<aggi>to investments, including modern infrastructure and technology

<aggi>and, i consider alot of bootstrappable related topics highly relevant, for a long-term perspecive

<aggi>"digital sovereignity" etc.

<aggi>so i've sent several dozen inquiries, again, to various universities, government startup funding offices, hr offices

<aggi>detangling the entire C-software eco-system from toolchain vendor-locks, simplified speaking, as a first measure

<aggi>ok, tinycc may be less relevant to bootstrappable, with plans "to remove tinycc"

<aggi>but currently, tinycc is the _only_ alternative remaining to detangle the C-software eco-system from GNU toolchain or llvm/clang (and with it c++)

<aggi>tinycc plus some assembler (yasm), sufficed here to bootstrap and "self-host" a typical GNUish/POSIX 100%, including kernel, boot-loader, and everything else

<aggi>of cause, you might try with cproc/qbe, simple-cc, kefir or any other - but with any of those chances are llvm/clang or gcc/binutils sneak into for some pieces

<aggi>hence, if the "long term plan" was to remove tinycc, there should too be a plan to develop a fully capable C-toolchain

<aggi>which fills the gap in live-bootstrap, and which can drive a complete GNUish/POSIX system

<aggi>ideally such a C-toolchain plus libc could be spawn from M2 directly

<aggi>the current situation in live-bootstrap is extremely, let's say, complicated; tinycc+musl-libc are recompiled more than a dozen times, for example

<aggi>i do follow the reasoning behind GNU mes development, regardless of some conceptual problems with it

<aggi>to my understanding that is a scheme-interpreter written in C involved, such scheme interpreter then hosts a C-compiler again written in scheme

<aggi>mes-libc is written in C instead, mes-cc isn't

<aggi>of cause, a LISP/Scheme bootstrap is necessary, i'm not sure however if that should be re-entangled into the C-toolchain bootstrap

<aggi>one argument to be made for GNU mes and mes-cc at that stage is support for various ARCH other than x86_32

<aggi>while i would prioritize any individual ARCH first, to liberate their bootstrap down to firmware - if that's possible at all

<aggi>and after all, nowadays bootstrappable is hovering above UEFI already, hence this issue has become moot to discuss

<aggi>then bootstrappable got two kernel options currently, fiwix and linux-tcc (2.4) - which can be compiled with a pure C-toolchain (other than the c++/gcc/llvm/clang dependency hell)

<aggi>live-bootstrap didn't bother with a make_bootable of those

<aggi>with those two kernel options that was x86_32 exclusive anyway, otherwise live-bootstrap always _must_ proceed with the whole dependency hell up until gcc/binutils to make_bootable any kernel

<aggi>i raise doubts if anytime mes-cc could compile any modern kernel for aarch32/64 or riscv64, even when all other preceeding bootstrapping stages were implemented (most are already in M2 from what i've seen)

<alganet>regarding M2 as a toolchain replacement, I think there is some merit in keeping it smaller and dumber, lots of early trade-offs there that enable it to be what it is

<alganet>I remember seeing something about mes directly building gcc 4.6, no tcc, don't know the current state of it https://cgit.git.savannah.gnu.org/cgit/mes.git/log/?h=wip-gcc4

<aggi>yes, and M2 already is sufficiently capable to spawn pnut-cc, mes-cc, i'm not sure yet about MES-replacement

<aggi>removing tinycc is problematic for other concerns than those exclusive to live-bootstrap

<aggi>because with tinycc there is a system integration route to make_bootable a fiwix or linux-tcc (2.4) kernel with hundreds of millions of code wiped from the dependency hell

<alganet>that middle kernel (what today is fiwix or linux-tcc) is a hard wall for other arches (aarch64, riscv64). Probably tons of backporting (linux-cc), porting+multi-arch work (fiwix) or a complete new kernel (kind of weird for bootstrapping, could introduce lots of autidability issues)

<aggi>yes, but i would say the hard wall is the dependency hell and hundreds of millions of lines of code introduced for all other

<aggi>and a make_bootable of fiwix/linux-tcc yields a fully capable development host to cross-compile for all other ARCH/kernels/etc.

<alganet>seems reasonable. I don't think a bootstrappable bootable fiwix image is hard to do. The live-bootstrap choice was to kexec in a single boot up to openela, which has its merits for their own purposes

<aggi>well, you'll need an assembler to process some pieces in syslinux/isolinux

<aggi>that's why GRUB2 is a little problematic, it's built rather late in the live-bootstrap dependency chain

<alganet>For ultra-long term though, eventually x86 will die (but that might be a problem for far in the future), that's what worries me about linux-2.4 and fiwix

<aggi>no doubt

<alganet>builder-hex0 can be used as a bootloader though. Slow, but doable.

<aggi>i will do the make_bootable fiwix/linux-tcc here (i would prefer fiwix even but for practical reasons sata/ahci/gigabit-eth/usb are real nice i would say, hence linux-tcc)

<aggi>but i will have to re-integrate ~500ebuilds into the build/packaging system from live-bootstrap

<aggi>that's all the stuff that got detangled for a C-toolchain driven system, i tried to salvage everything possible

<aggi>for a bootstrap it can be much less

<aggi>but i too wanted to proof my point here, a GNUish/POSIX system can be maintained with a C-toolchain

<aggi>then again, this brings me back to german government and their "special budget" and a giant stack of denials i had received

<aggi>because i'm not in the mood anymore to do all this work, besides a little conceptual reasoning

<alganet>for me it's simpler, I got no money or sponsorship, it's a hobby-only thing (I just thing it's neat having bootstrappable systems)

<alganet>your idea is nice, I hope you complete it

<aggi>well, the C-toolchain detanglement is done already

<aggi>it's only some menial system integration tasks remaining, a hobby as you've said

<alganet>linux-2.4 early with networking is also a huge plus, opens all sorts of possibilities by not requiring the image to have all packages up to curl/ca on linux-4

<FransFaase>aggi: With my GNU Mes replacement solution, it now builds stage0, tcc-0.9.26 and tcc-0.9.27 in within 2 minutes for x86_64. Similar times for x86 and arm64. I am going to work on supporting riscv64 next.

<FransFaase>For adding riscv64 it is only needed to implement a relatively straight forward mapping of a simple stack based language (with two stacks) on machine code.

<aggi>FransFaase: at the time when i tested mes-replacement there had been some pieces missing, and pnut-cc was confirmed already

<aggi>which means, i'm willing to swap pnut-cc for mes-replacement anytime, that's not problematic

<aggi>i merely want to keep focus on the complete system-integration of this

<aggi>FransFaase: shall the MES-replacement become a fully capable C-toolchain anytime in the future?

<aggi>simplified speaking M2 -> MES-replacment that was capable to compile/link fiwix/linux2?

<aggi>of cause, pnut-cc isn't neither, hence the route M2 -> pnut|mes|... -> tinycc

<aggi>FransFaase: the twist seems to be, anything which could compile tinycc already is a prime candidate to fully replace tinycc as a complete C-toolchain

<FransFaase>The tcc_cc compiler is a minimal C compiler to be able to compile tcc and the necessary tools, like untar. It was not intended as a general purpose compiler and does not support all C features. It also does not produce object files, has no linker and such. It can compile a number C files (assuming that they do not have static variables with the

<FransFaase>same name) into a single Stack-C file, which acts as an intermediate language. For each target there is a compiler that compiles Stack-C to assembly, which needs to processed with blood-elf, M1, and hex2 into and ELF.

<aggi>seems pnut-cc is conceptually different to mes-replacement

<aggi>ok.

<FransFaase>The T-diagram up to tcc-boot0 can be found at https://fransfaase.github.io/MES-replacement/Tdiagram.html

<aggi>i think i can grasp the reasoning, pnut-cc produces an object file / executable, for x86_32

<aggi>while mes-replacement emits macro-assembly to be processed by M2 for various different ARCH (simplified speaking)

<FransFaase>The diagram is generated from the output of a strace command. The green boxes show which processes are execute by which process. All the processes executed by process 21 are used to recompile the input sources and verify that they are the same, which is indicated with the blue lines.

<aggi>that's something else pnut-cc didn't take into account, dependency tracing - it's some simple and fast c-compiler as a drop-in replacement for mes-cc

<FransFaase>aggi: It uses a very simple compiler (almost one-to-one) to compile Stack-C intermediate language (basically a post fix C language) into M1 files for the various targets into M1 format.

<aggi>ok, while reviewing live-bootstrap at first i've begun to copy-over each individual c/h file to grasp a picture of all dependencies

<aggi>after all, GNU mes is a huge project

<aggi>but then gave up because it wasn't practical anymore to track all #include

<aggi>hence i can grasp the reasoning behind the desire for some compile-time dependency tracing

<FransFaase>aggi: That is also what I started to do some years ago. I also have a T-diagram for live-bootstrap, which is a bit bigger. See: https://fransfaase.github.io/Emulator/tdiagram.html

<FransFaase>My main motivation for MES-replacement was to create an easier to review stage0 as I explained in the talk I gave at WHY2025. That is why I use a modified hex2 that can generate hex0 output with assembly and Stack-C in the comments to shows the relationship between the actual hexadecimal code with the C statements.

<aggi>my initial concern to favor pnut-cc was compile-time performance for fast trial-and-error re-compilation cycles while re-integration various steps/

<aggi>reviewing all of those which shall be re-integrated from gentoo/ebuild packaging into configurator/steps

<aggi>a whole other aspect, to abstain from gcc, compile time performance

<aggi>for now it's probably best to separate those concerns, of MES-replacement and the full re-integration of a C-toolchain system-integration

<aggi>i'll keep an eye on MES-replacement, but here it's mainly all the work tbd once tcc is available

<alganet>the original vision of mes (not exactly only mescc) is kinda nice, the posix shell would also be served by a lisp interpreter (gash and gash-utils). It's lisp as a tabula rasa milestone in the process. In theory, it's clean, forward compatible with guile and so on

<alganet>but the slow compilation times really hurt iteration right now

<alganet>lots of ideas in bootstrapping, from practical to more theoretical, and it's sometimes hard to concilliate them all in a single vision (which is probably fine, free software is like this)

<aggi>i only hope FransFaase isn't mad because i've picked pnut-cc, because his dependency tracing approach of early stage0 is highly relevent too

<alganet>in theory, live-bootstrap supports (with little effort) holding multiple paths in the same repo, just changing the main manifest that picks from them. It incurs more CI work though, testing and so on. So there's a world in which mes, mes-replacement and pnut-cc coexist, maintained within a bootstrap system

<aggi>and i've too forked from live-bootstrap, since the statement was made to remove tinycc, which on the contrary angers me a little bit (not that it matters)

<aggi>ideally this fork will not divert, and various steps-tiny/ can be picked if desired (let's say yasm, cdrtools, busybox, linux-tcc)

<alganet>There's a lot of work in the automation/scripting/arrangement of stuff, it's kind of hard not to use live-bootstrap. I decided to part from it (at least for now) though.

<aggi>i've got another idea besides, just as said to keep the base-system package set for a complete(!) development hose make_bootable much smaller than live-bootstrap did

<alganet>One of my goals is to replace kaem for a full POSIX shell that can build from M2-Planet, and then build the orchestrator on pure shell. More familiar, forwards-compatible, fits make/sh expectations http://github.com/alganet/hs

<aggi>and implement some manifest-generator for some package dependency management for several hundred of those ebuilds

<aggi>some sane and simple build/packaging that configurator/steps already is, plus some dependency tracking (instead of rushing towards guix/nix or gentoo)

<aggi>yep, kaem scripting is a tad bit limited (which too was biting stage0 already to pass along some ARCH variable for example)

<aggi>and the way how control-flow is passed to configurator/steps was a little confusing at first glance

<aggi>currently i got one more month remaining up until when german government who knows what comes up with next

<alganet>I plan to work for at least one more year polishing the very early post-firmware bootstrap. Eventually I'll need to test further steps (having a builder-hex0 in riscv64 that completes stage0 is different from having one that can build fiwix, lots of challenges still), but my goal is completeness on that lower layer, break out of x86-only.

<alganet>hopefully I'll be able to meet other efforts in the middle

<Googulator>aargh, mescc compiling GCC 4.6 sounds like a world of pain...

<Googulator>~30 minutes spent compiling tcc 0.9.26-patched on one core of a Core 2 with dual DDR2-800 in Fiwix (although it seems to scale with RAM bandwidth on newer systems, but I exclude those due to the risk of chip-level compromise)

<Googulator>extrapolating from that, GCC 4.6 sounds like something that will take weeks

<Googulator>and yes, I'm aware of attempts to speed up mes, but I still don't believe that a speedup of multiple orders of magnitude can be achieved

<matrix_bridge><Andrius Štikonas> How many files are in GCC?

<matrix_bridge><Andrius Štikonas> A lot of them are never built with tcc but are with xgcc

<matrix_bridge><Andrius Štikonas> Still probbaly hours and hours of building

<Googulator>also, tcc already stretches mescc to its breaking point, spitting out several scary errors/warnings during that painfully slow compilation - but miraculously, it does produce a binary, and that binary is then good enough to recompile itself

<Googulator>It's probably some terribly unoptimized code in mescc itself, but I doublt anyone understands mescc's code well enough to be able to optimize it

<Googulator>all of the speedup work seems to be going into speeding up the mes interpreter, not mescc

<Googulator>stikonas: xgcc is AFAIK used to build the runtime libraries only (+ rebuild itself if gcc's bootstrap is enabled)

<Googulator>I misremembered, the ~30min build runs in builder-hex0, not Fiwix

<Googulator>that means 2 things: 1) BIOS overhead is involved

<Googulator>2) we have no hope of building gcc at the stage when we currently build tcc (we have no make, no real shell, no ability to run processes in true parallel, even on a single core, and an extremely limited in-memory FS that can't even delete or rename files)

<Googulator>even if a newer mes can run gash, and someone writes a mes-compatible Scheme reimplementation of make, it will work running on a Linux kernel, but not in builder-hex0 due to kernel limitations

<aggi>and a whole other aspect, in favor of c++/gcc/binutils/llvm/clang - it was not possible to maintain a complete GNUish/POSIX development host without those before

<aggi>but the entire detanglement of free/open C-software for support with tinycc (or any other future option in it's place), was demonstrated

<aggi>i'm just not willing to git-push the gentoo-portage chaos, and rather do a clean re-integration into live-bootstrap steps/

<aggi>otherwise, all this work was done already, i got such development host up and running for several month already (including the irc-client here)

<aggi>it's all backported onto linux2 abi already, statically linked with tinycc

<Googulator>see also: the recent effort to add a Guix bootstrap as an optional extension of live-bootstrap, using a secondary steps directory

<Googulator>but fossy seems to have an issue with that approach

<aggi>this too establishes a baseline for any other such approach (cproc/qbe, kefir, simple-cc) or whichever c-toolchain there could be in the future

<Googulator>out of curiosity, why doesn't efraim's gcc-4.6 fork count as a "C toolchain"?

<Googulator>it's forked from before GCC started to be rewritten in C++

<aggi>i would say it does qualify as c-toolchain, but it remains a different GNU beast by design, in comparison

<aggi>furthermore gcc is entangled into the GNU buildsystem, together with it's brother binutils

<Googulator>what's wrong with binutils?

<aggi>which builds up a gigantic dependency graph elsewhere (perl/autoreconf, then a few more makefile generators which needs scheme/guile)

<Googulator>Isn't a Scheme dependency only in GCC 10.x and beyond?

<Googulator>(Perl, obviously, is an issue much earlier)

<aggi>i think too gcc-4.x was affected by this, hence live-bootstrap had to extensively patch into gcc4.x build-system

<Googulator>AFAIK it just skips the top-level makefile

<Googulator>also, if I'm not mistaken, efraim did patch that, either to remove the Scheme dependency entirely, or to make it work with mes

<Googulator>not efraim, ekaitz

<aggi>to avoid a misunderstanding, i'm not opposed to gcc/binutils

<aggi>i'm opposed to the idea tinycc was removed _without_ an alternative in it's place

<aggi>and the whole mes-cc/gcc approach raises more questions than it could answer

<aggi>same with fiwix/linux-tcc (2.4) type kernels, i'm not opposed to the linux5 strategy itself

<aggi>but instead the chance was missed so far to make_bootable a fiwix/linux/tcc system much earlier with hundreds of millions of lines less dependency hell

<deesix>aggi: where is tinycc removed without alternative?

<aggi>deesix: first, janneke merely proposed this three month ago

<aggi>deesix: then next, there seems to have been some dispute between tinycc-devel and bootstrappable with the consequence tcc-0.9.26 fork persisted and a few changes to tcc-0.9.26 had not been rebased onto tcc-head anymore for many years already

<deesix>None of that is "was removed", AFAIU.

<aggi>2026-03-14 18:09:50 <aggi> janneke> and also, imho, we should, in our long term planning, have a way to remove tinycc from the full-source bootstrap

<aggi>2026-03-14 18:10:38 <aggi> to clarify, it's the transition from M2 towards any fully capable C compiler which is critical

<aggi>2026-03-14 18:11:57 <aggi> the latter seeking "self-hosting", and in this regard GNU/g++/binutils are a _worse_ liability than tinycc

<deesix>I saw you repeating that... but again, that is NOT "was removed" as you are interpreting it, please!

<aggi>deesix: that's not past tense, but "konjunktiv" in german language and too english language

<matrix_bridge><Andrius Štikonas> There is also no centralised authority here

<matrix_bridge><Andrius Štikonas> One person might remove tcc from their chain, somebody else might remove mescc...

<matrix_bridge><Andrius Štikonas> Somebody else might remove C entirely

<matrix_bridge><Andrius Štikonas> And write everything in forth

<matrix_bridge><Andrius Štikonas> Or maybe rust or something else

<aggi>nonetheless, there seems to be projects receiving funding, others don't

<aggi>since you mention rust, they were granted dozens of millions by the helsing.ai realm, EU/UK cash, drowning in it

<aggi>so, after all, there must be some "authorities" involved somewhere, who made those decisions

<ekaitz>aggi: i'm was trying not to take part in the discussion but as I've been mentioned, i'll do

<ekaitz>tinycc is just a pain in the balls to deal with from the bootstrapping perspective

<ekaitz>the managment they do is poor and the codebase is really hard to understand

<ekaitz>if (o(v.c) != -1)

<ekaitz>and things like that

<ekaitz>they have been very confrontational with us

<ekaitz>and the way the maintainers talk is simply offensive

<ekaitz>i have 0 need in life to interact with such a project

<ekaitz>so, if i can avoid it I will

<ekaitz> https://github.com/mirror/tinycc/commits/mob/?author=ekaitz-zarraga and it's not like i didn't interact with it in the past

<aggi>ekaitz: do you see any realistic chance pnut-cc could evolve into a fully capable C-toolchain as drop-in replacement for tcc?

<ekaitz>i don't care

<ekaitz>i'm more into working on MesCC and hope it gets good enough for gcc-4

<ekaitz>i actually like people opening new bootstrapping paths, mine is with Mes

<ekaitz>i don't care much about anything else, really

<ekaitz>i would even enojoy trying to leave M2 behind and bootstrap in a different way

<Googulator>Would the bytecode interpreter help mescc perform with a run time competitive with tcc/pnut, or even a modern gcc (which is far slower because it spends a lot of CPU time optimizing)?

<Googulator>Or is it, as I suspect, an issue with mescc itself, rather than the interpreter?

<ekaitz>i'd say both

<ekaitz>there are many wins available with the new interpreter

<ekaitz>but we have to take them

<ekaitz>mescc uses match a lot, which can be compiled to very efficient code, but we have to make sure that happens

<ekaitz>i'll first make the interpreter fast, and then focus on mescc being faster

<ekaitz>i don't think it's going to be competitive (in speed) with tcc

<ekaitz>i mean, ever

<ekaitz>tcc is very fast

<ekaitz>even for compilers in general

<Googulator>That's why I mentioned a modern gcc as a benchmark

<ekaitz>about that, i don't know

<ekaitz>a test we can do is run mescc with guile

<ekaitz>i'm not going to make the interpreter as fast as that

<ekaitz>no chance

<ekaitz>that's basically our ceiling

<Googulator>maybe I should've phrased differently: can we ever make mescc's runtime be limited by available CPU cycles, not memory bandwidth?

<ekaitz>i'd say that can certainly improve a lot

<Googulator>Right now (in the version used by live-bootstrap), running mescc generates memory controller load comparable to running llama.cpp on the CPU

<ekaitz>that is basically what i've been working towards during the last... year

<Googulator>although I'm not sure how much of that comes from using an ancient version of nyacc

<ekaitz>i'd say most of it is mes' tree walk

<ekaitz>bytecode certainly improves that

<ekaitz>but there is some inlining and stuff we can do

<ekaitz>we need to make this thing first work properly and then optimize

<xentrac>aggi: if someone is looking for a smallish C compiler written in C, there does exist Johnson's pcc which the OpenBSD folks were reviving

<xentrac>not sure how hard it is to compile though

<aggi>xentrac: i was looking for a complete(!) system-integration with a sane and simple c-toolchain (other than the modern hyper-scaled complex ones)

<xentrac>yeah

<aggi>and this is what i got already, i'm in no hurry at all, but not too motivated either to proceed for various reasons

<matrix_bridge><Andrius Štikonas> Googulator: new nyacc is worse in terms of time

<matrix_bridge><Andrius Štikonas> It supports more c features, so parsing is longer

<mwette>I've copied the c parser code out of nyacc-3 to create something hopefully better. I've replace syntax-rules w/ define-macro. Still uses match but you have that code. Also, not copying comments through. And the comment-preserving rules in the grammer could be stripped out. Also stripping out unused code.

<mwette>The new code will parse all the non-arch-os-dependant tinycc/{*.c,lib/*.c} files.

<mwette>currently

<mwette>Trying to make room to strip down the need to support guile features.

<mwette>Do you care about source properties? Stripping that out will save.

<siraben>ekaitz: I'm working on making hcc be able to compile gcc-4

<ekaitz>siraben: what's hcc? do you have a link to it?

<siraben>ekaitz: https://github.com/siraben/blynn-bootstrap/tree/master/hcc

<siraben>I've removed MES and replaced it with bootstrappable Haskell from Ben Lynn (blynn)

<siraben>No parser generator, for instance https://github.com/siraben/blynn-bootstrap/blob/master/hcc/src/Hcc/Parser.hs

<ekaitz>why is everybody removing mes? hehe

<siraben>I had an idea to do this like 5-6 years ago but didn't have the time to do it

<siraben>ekaitz: I also have a fork where I replace kaem with bake https://github.com/siraben/live-bootstrap-bake

<siraben>"bootstrappable make"

<siraben>bake files look like this https://github.com/siraben/live-bootstrap-bake/blob/master/bake-files/steps/make-3.82/pass1.bake

<ekaitz>oh ok

<xentrac>Haskell C compiler

<FransFaase>xentrac: And how is the Haskell interpreted?

<siraben>FransFaase: It's compiled to combinators and run on a VM in C

<siraben>This patch makes it compile with M2-Planet https://github.com/siraben/blynn-bootstrap/blob/5fa4e5271b2f0817de544c04a7aa92a2595e6823/patches/upstreams/blynn-compiler-local.patch

<roconnor>I'm working on a replacement of the C VM with one written in riscv-M1.

<FransFaase>ekaitz: One reason to replace mes is because is kind of slow. Another reason is that it uses a non-C language. I think it is a bit wierd to have a minimal C compiler (M2), use that to compile an interpreter written in C that is used to implements a C compiler that is strong enough to compile the Tiny C Compiler.

<samplet>Hence why I’m working on my Mes replacement that avoids C and M2. lol

<ekaitz>haha

<ekaitz>having a non-C language is not necessarily an issue. Mes increases the abstraction level a lot

<ekaitz>that's a huge advantage

<roconnor>If I'm successful we'll have M1 -> Haskell(ish) -> hcc -> tcc ... setting aside the fact that my VM only runs on RISC-V and tcc only runs on x86

<roconnor>:P

<janneke>one of the initial ideas for gnu mes, was to step away from low-level c-like languages as soon as possible, and go to a high-level, clean, and functional language

<janneke>sure, we're not there yet, and yes, mes is slow

<janneke>some of us are working on both of these issuse, though ;)

<janneke>but hey, for those who love all kinds of c-like language dialects, please continue to create new ones ;-P

<samplet>For sure. I bet the Haskell approach is nice to work with. ML is great too. All three languages (Scheme, ML, Haskell) are basically siblings.

<janneke>yes, maybe my last remark came out a bit more corny than i intended: we're all #bootstrappable here and we want to get rid of binary blobs

<janneke>diversity is most always good

<roconnor>FransFaase: BTW, does your Stack-C use no heap?

<roconnor>(I just watched your talk)

<FransFaase>roconnor: Yes it does. There is a sys_malloc function that allocates memory. Memory is never freed.

<roconnor>Where do you need to use it?

<ekaitz>roconnor: to increase the stack size LOL

<ekaitz>:)

<ekaitz>ACTION is just joking (but it's a good gues I believe)

<FransFaase>The programs that compile Stack-C to M1 do not allocate memory. They simply use global variables of which the size is large enough for what it needs to compile everything up to tcc-0.9.26.

<roconnor>It's true that now that I think about FransFaase said he uses two stacks.

<FransFaase>roconnor: Yes two stacks: one for expression evaluation (including arguments and results) and one for local variables (and return addresses). I understand that many Forth interpreters do the same.

<xentrac>FransFaase: weird is good if it works

<FransFaase>Mixing the two stacks introduces a lot of complexity. The second stack (for the local variables) is allocated at the start of the program with a fixed size. The size is set large enough for all the sources it has to compile, but will lead to (very unpredictable) crashes when it is used up.

<FransFaase>Complexity with respect to code generation.

<xentrac>it's common for C compilers to maintain expression evaluation stacks only at compile time

<xentrac>or Scheme compilers, Haskell compilers, etc. Even some Forth compilers manage it some of the time

<ekaitz>mes now has just one stack

<ekaitz>it is tricky though

<mwette>Removing source-properties seems to reduce parse time 20%.

<mwette>(in guile)

<siraben>janneke: re: diversity, since it's bootstrappable it inherently makes it good as an example for people learning compilers or programming, since the language complexity is capped per stage

<siraben>and bootstrapping tcc makes it real enough instead of just being a toy example

<siraben>Still waiting for a brave soul to do a Forth-based bootstrap though :P

<janneke>ACTION has had to hear for about 10y how this would all be ever so trivial in forth

<aggi>stupid question: what's the difference between forth and programming assembly?

<aggi>such as, implementing a c-compiler in assembly language, or implementing it in forth i mean

<xentrac>janneke: Forth only makes it look trivial afterwards. debugging it is not trivial ;-)

<xentrac>aggi: I like Forth but it contains a certain number of traps for young players. because you *can* do everything on the stack you tend to try to do so, which is usually disastrous; I wrote about that at greater length in https://news.ycombinator.com/item?id=33264506

<siraben>Debugging this was miserable https://github.com/siraben/meta-yacc

<xentrac>usually, Forth takes about as much code to implement given functionality as C does, although typically formatted a bit more horizontally; they're languages of about the same abstraction level

<siraben>But I did get to a parser generator self-hosted in Forth

<xentrac>C is better at catching bugs at compile time because it has a type system and you can't pass an argument to the wrong subroutine, while Forth is better at metaprogramming and factoring

<xentrac>but both of them take a *lot* less code than assembly language does

<siraben>xentrac: one language has actual recursive expressions that at least ensure some sanity before running

<xentrac>yeah, Forth doesn't attempt to ensure anything before running, ever

<xentrac>that's awesome though!

<siraben>I think there is some middle ground that is possible, maybe some lispy Forth? you don't need full closures that capture their environment, but just some way to build abstractions in a functional manner would be very powerful

<siraben>Ah, well qfitzah is like that

<xentrac>yeah, there are certain things (especially in compilers) that would benefit a lot from a heap

<xentrac>yeah, Qfitzah is a lot smaller than any Forth

<siraben>You can make the argument that "term rewriting is all you need"

<xentrac>at least 2×, maybe 4× (discounting things like Sergeant's "3-instruction Forth")

<xentrac>yeah, I did try that argument out in Qfitzah, but I'm not sure if I really buy it yet

<siraben>lisp in qfitzah: https://github.com/siraben/qfitzah/blob/main/examples/lisp.qf1

<siraben>it does need native numerics

<xentrac>probably yeah

<xentrac>it *really* needs byte I/O

<siraben>yeah I implemented that actually, just write though

<xentrac>I think for practicality it probably wants native numerics and some way to handle arbitrary-arity terms (so you can cdr down a list of arguments or something)

<xentrac>also maybe a garbage collector if you wanted to use it for more than just an initial bootstrap

<xentrac>speaking of yacc, have you seen Meta-II? My version is called "meta5ix": https://canonical.org/~kragen/sw/dev3/meta5ixrun.py

<siraben>Yes I've seen meta-II, which inspired my project called meta-yacc

<siraben>hmm I should have called it something else, it's not LALR at all lol

<siraben>it's just LL(1)

<siraben>xentrac: your cert is expired!

<xentrac>oops, sorry, http://canonical.org/~kragen/sw/dev3/meta5ixrun.py

<xentrac>I should probably change some of the Meta5ix syntactic decisions

<xentrac>oh, I see I added a comment about that :-)

<siraben>Another interesting bootstrap base is trompc's binary lambda calculus, I believe

<siraben>There's also Tree Calculus, which I don't understand yet https://treecalcul.us/

<siraben>trompc: https://tromp.github.io/cl/cl.html

<xentrac>yeah, BLC is cool

<siraben>On December 22, 2025, Discord user 50_ft_lock optimized the blc interpreter down to 170 bits using what seems at first like magic.

<xentrac>oh interesting! I hadn't heard about that

<xentrac>my favorite minimalist calculus is Abadi and Cardelli's object calculus (the ς-calculus)

<xentrac>{..., f = ςx: e, ...}.f reduces to e[{..., f = ςx: e, ...}/x], analogous to the λ-calculus's β-reduction (but intrinsically recursive), but there's also a second reduction rule

<siraben>Ok looks like getting hcc to compile gcc46 isn't really the right move here, it's going to add a lot of complexity, unfortunately.

<xentrac>{..., f = g, ...}{f = h} reduces to {..., f = h, ...}

<siraben>Ah yes, object calculus is cool.

<xentrac>it's almost as simple as the λ-calculus or SKI-combinators but a lot more usable

<xentrac>in a human-interface sense, I mean

<xentrac>Jeannette Wing likes the π-calculus but I don't understand it well enough to have an opinion yet

<siraben>Has anyone packaged up the bootstrap work into a webpage anyone can run?

<siraben>in the spirit of JS-linux, and for masochists

<siraben>π-calculus is for processes I believe, not as good for computation but good for describing concurrent systems

<xentrac>yes, in the π-calculus the fundamental objects are processes, but it's just as computationally universal as the λ-calculus

<matrix_bridge><cosinusoidally> siraben: I wrote https://github.com/cosinusoidally/mishmashvm/blob/dev/tcc_js_bootstrap/alt_bootstrap/bootstrap_proto17.js which can run stage0-posix-x86 under the Mozilla Spidemonkey JS shell. It's essentially enough of an emulator of the x86 linux userspace to allow stage0-posix to run. Takes hours though.

<matrix_bridge><cosinusoidally> iirc it can actually get up to cc_x86 in a reasonable amount of time, but getting to the end of stage0-posix took hours. At that time there was no alternative to mes and I didn't fancy trying to run that under emulation.

<matrix_bridge><cosinusoidally> My original plan was to run all the way up to tcc via that emulation, which is one of the original reasons I wanted to bypass mes.

<siraben>I see

<siraben>Heh, everyone wants to bypass or remove MES!

<siraben>There's something very nerd-sniping about that

<siraben>Oh my, I never merged my portable script PR to blynn-bootstrap

IRC channel logs

2026-06-04.log