IRC channel logs
2026-06-03.log
back to list of logs
<FransFaase>Last weekend someone send some pull request for my MES-replacement project for stage0 (made with the help of Claude Code). He want to incorporate it into spack.io (a package manager for supercomputers, Linux, macOS, and Windows) together with the rest of live-bootstrap. The reason is that some people within HPC do want to use bootstrapping as part <FransFaase>of their process to not having to reply on certain compilers. <FransFaase>He got as far as having tcc-0.9.26 self compile for x86_64/amd64 and arm64/AArch64 with some patches to the tcc-0.9.26. He also found some bug in my compiler related to continue appearing inside a switch statements not jumping to the right location. <FransFaase>However, when tcc-0.9.26 is used to compile tcc-0.9.27 it returns errors, which are different for both targets. I also understand that some of the older GCC versions do not support code generation for arm64 and that the code generation needs to be back-ported from a version that does. <FransFaase>We are looking for advice and cooperation on supporting 64 bit targets for live-bootstrap. <Googulator>FransFaase: was that user "stabbles" from here on #bootstrappable? <alganet>FransFaase: I'm doing some work on 64bit support (riscv64, aarch64). Currently working with GNU mes, but once I finish I'm interested in exploring the Mes-Replacement path as well. <alganet>I also got riscv64 support running on stage0-uefi (up to posix-runner.c compiling mes-m2), still polishing it though. <alganet>I'm using AI assistance, and it's all public. If anything sounds like it could help you, let me know. <FransFaase>alganet: The pull request also contain patches for tcc-0.9.26 to support aarch64 code generation. There is a adapted pass1.kaem to apply the simple patches and include some extra files. The resulting tcc-0.9.26 can be used to compile itself. However, it does return an error message when used to compile tcc-0.9.27, which I have not investigated yet. <FransFaase>alganet: Where can I find your work on riscv64? The Mes-replacement does not have support for riscv64 yet. <alganet>Maybe it will not be directly useful, since uefi is so different, but might provide some references or ideas. <FransFaase>I see that the reason for the error I am getting when trying to build tcc-0.9.26 might be because in steps/tcc-0.9.27/pass1.kaem is uses: '-D TCC_TARGET_I386=1' <FransFaase>alganet: I understand that you are writing assembly versions for a number of the initial steps. In my MES-replacement, I all compile these from C sources. <alganet>FransFaase: regarding the tcc loops, they're kind of sensitive. In previous tests of mine, sometimes an earlier tcc build would seem to compile fine but fail in a much later step (musl, for example). It's finnecky. Good catch on I386 flag though! <alganet>FransFaase: I'm aware that you have some sort of emulator project as well, is your idea to overcome some arch limitations by using it at some point? <alganet>FransFaase: the assembly stuff can't be avoided up to M2-Planet, so, yes. I'm not very good at it :D learning a lot while I do this. What I'm doing is mostly following existing stuff for x86 but filling incomplete archs on the full kernel bootstrap from bottom-up (I started with builder-hex0) <alganet>FransFaase: I'm not at tcc yet, so perhaps at some point we can meet in the middle, with me offering the builder-hex0 kernels that boot from firmware only and provide an usable stage0 environment for all architectures. My work might not be exactly useful for the supercomputer supply chain guy you mentioned though. <aggi>alganet: an important apsect of MES-replacement had been dependency-tracing during compilation which Frans explained in one of his presentations online (youtube) <alganet>aggi: Thanks, I need to watch the presentation and get my hands dirty with mes-replacement at some point. I'm almost done with self-hosting mes (I'm too far ahead to give up now), so it's my priority for now, but I'll definitely take a deeper look before jumping to the tcc steps. <FransFaase>alganet: The Emulator project was my second attempt in reviewing/verifying stage0 for x86. See: https://www.iwriteiam.nl/Hackfest_2024.html and search for Emulator and click on the show button to see some more details and links to all the blog posts (which sometimes do not give much information). <mwette>mes team: I'm looking into extracting mes dep's (w/ conversion to define-macro) as a small number of files, which could conceivably be rolled into mescc. <janneke>mwette: sure, thanks for the headsup! <mwette>janneke: it would be useful to know if you use any extras like cxeval or munge. <janneke>mwette: we don't, we only use parse-c99; but possibly live-bootstrap? <janneke>i believe they generate some things, stikonas or flossy should know <matrix_bridge><Andrius Štikonas> Live-bootstrap builds those mach.d files on top of what mes build in fuix does <mwette>OK. So I assume mes does not use any post-parse tools like cxeval or munge. <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 <xentrac>tinycc can probably run on smaller computers than any recent GCC <Googulator>AFAIK the problem is more the poor code quality of tinycc <Googulator>coupled with the attitude of current maintainers <xentrac>poor code quality in the sense of the inefficiency of generated code, which is probably inherent to being a very minimal non-optimizing compiler, or in the sense of correctness? <aggi>the machine code produced by tinycc yields decent performance <aggi>i've succeded with re-integrating almost _everything_ that was written in C for compilation linking with tinycc <aggi>up until things like ffmpeg/mplayer-1.4, prboom - which i haven't got benchmarks for, but those multimedia pieces which often do benefit from "optimization" run just fine with what tinycc does <aggi>and, which maintainers? there's probably not many, with whatever attitude towards whom? <aggi>a long term perspective could be this: M2 -> tinycc; or M2 -> any other compiler such as pnut; or M2 -> GCC/binutils <aggi>a criteria being, any compiler should at least be capable to compile what tinycc already does, including any kernel and a few other things <aggi>for the record, even a gcc4.x cannot, officially, compile any linux5/6 anymore, it's a total mess what they've done <xentrac>things like ffmpeg generally run their inner loops in assembly <aggi>xentrac: i've not activated the optimized assembly routines because tinycc assembler couldn't digest everything there iirc <aggi>but tinycc assembler sufficed for syslinux pieces, for all else i've pulled into yasm already, to avoid binutils <aggi>xentrac: recently i've begun moving all builds from gentoo-portage into the steps/configurator packaging <aggi>it's another 400ebuilds to go until i'll arrive at mplayer/ffmpeg again <aggi>just as said, i detangled almost everything possible from gcc/binutils/clang <xentrac>ACTION sprays detangler on the source tree <aggi>plus the backport onto linux-2.4 syscall abi <aggi>i've had a glimpse at it's source myself already, and hell yes am i scared from what i've seen <aggi>but looking at it from the system-integration perspective, at least i could demonstrate free software can be detangled for maintenance with a C-toolchain <aggi>for any other future one, which wasn't GNU/gcc/binutils or llvm/clang <aggi>i would even be willing to give mes-cc a try, if that suffices to compile/link linux-tcc kernel fork <xentrac>I think I've only ever looked at the original tinycc source that was written as an entry for the International Obfuscated C Code Contest <aggi>to kick out gcc/binutils and with it GNU buildsystem <aggi>"in our long term planning" <mwette>stikonas, janneke: Do you care about c99 comments included in the parser output? <stikonas>I don't think I do but janneke would know better <mwette>We can do this later, once the initial cut is working. <mwette>There are other time-saving items that could be cut also (e.g., source properties). <janneke>yeah, currently having comments is not our concern ;)