IRC channel logs

<Frans>Hello, I am Frans Faase and my website is iwriteiam.nl. I am working on a replacement for the GNU Mes compiler in stage0. I have given a presentation about this on WHY2025. The project got some funding from NLNet.

<Frans>Currently, I am looking at kaem-optional-seed and I was wondering if there is also a C program available that describes what it implements besides the kaem-optional-seed.hex0 file.

<ekaitz>Frans: what are you trying to do instead of GNU Mes?

<ekaitz>Frans: (NLNet funds my work in GNU Mes)

<ekaitz> https://media.ccc.de/v/why2025-139-reviewing-live-bootstrap okay this is the talk I believe

<janneke>Frans: replacing GNU Mes, the heresy! ;)

<ekaitz>janneke: i'm kind of replacing GNU Mes, too

<ekaitz>:)

<janneke>ekaitz: sure, and samplet is :-D

<janneke>well, being replaced is a lot better than being ignored i guess, esp if the replacement is better

<Frans>I have already finished a C compiler that can compile tcc-0.9.26. The compiler produces an intermediate representation in a stack based language, which I called Stack_C.

<Frans>I also wrote compiler for Stack_C that can produce a M1 file for x86, which can be compiled with the stage0 tools into an executable.

<Frans>For my progress and project plan, see: https://github.com/FransFaase/MES-replacement

<ekaitz>oh that's great

<ekaitz>Frans: just for you to know, i'm working on making Mes faster

<ekaitz>I agree that Mes is kind of in a weird situation there, but we can still use it for a few things

<ekaitz>my goal with Mes is to make it good enough to remove TinyCC

<ekaitz>(good and fast)

<ekaitz>I hate the TinyCC code with all my heart

<ekaitz>basically, what I see in the repo is you are doing some kind of a GNU Mes but with a different base language, in your case Stack-C

<janneke>ACTION hopes for MesCC to grow into MesC++ some time so that we could build gcc-7 or something :)

<ekaitz>janneke: ugh! C++ is probably too much

<ekaitz>but we'll see

<ekaitz>maybe we can make GNU Mes a multi-language compiler :)

<Frans>I did experience my share of problems trying to compile the TinyCC compiler. I have remarked in one of my blogs that TinyCC its own unit test.

<janneke>ekaitz: only just enough c++ for gcc-7?

<janneke>but we'll see!

<Frans>The nice thing about TinyCC is that you can compile it as a single source file, without creating object files and without having to implement a linker.

<janneke>in any case, exciting Frans!

<janneke>ACTION will be looking at Frans' talk later

<janneke>sure, and it can compile gcc-4; tcc is great because it helped us show a full source bootstrap is reasonable and feasible

<ekaitz>i also downloaded the talk for later, very interesting!

<ekaitz>Frans: we can also try to help you implement the riscv64 backend

<ekaitz>we have quite a bit of experience with the riscv64 part of the bootstrapping chain

<Frans>Great if you want to help me with the riscv64 part. At the moment I am focusing on the Task 2 and 3. I already did some work on Task 4.

<ekaitz>let us know if you need help

<ekaitz>i ported basically a lot of software to riscv64, including a big chunk of tinycc

<Frans>@ekaitz: I will let you know when I need some help. I guess, I will have to write an alternative for the Stack_C language. For x86 it uses two stack solution, where one stack is used for expression evaluation and the other for storing local variables and return addresses. I presume that a similar solution will be possible with riscv64.

<Frans>And my C-compiler also needs some change to support 64-bit pointers. Now it assumes that everything is 32-bits. x86_64 will also need 64 bits support. The Stack_C language might also need some small additions.

<ekaitz>ACTION went for a run and is back again

<ekaitz>Frans: in riscv you should be able to do the same with no issue

<sh4>Frans, did you see this?

<sh4><LaurentH> [13:10:13] https://github.com/udem-dlteam/pnut/blob/main/doc/thesis.pdf

<sh4><LaurentH> [13:10:25] ^ I recently submitted my master's thesis arguing for the use of POSIX shell for reproducible builds and diverse double-compilation

<aggi>made progress with stabilizing linux-2.4/tcc kernel

<aggi>driver backport for ax8872 asix.c seems stable now, with large network packets and heavy load too

<aggi>then verified the rebased nptl patchset with it, avoid_set_thread_area.patch from musl-libc-1.1.24 is not needed anymore wiht linux-2.4

<aggi>interestingly, almost all of 500ebuilds ported onto linux2/tinycc/musl did not need pthread_create, but i've finally hit one binary which did error-out with ENOSYS

<aggi>that's relevant, because NPTL can remain fully optional to retain a self-hosting GNUish/posix still

<aggi>while runtime-testing with self-hosting compilation it's been unsquashfs binary only which actually does need pthread_create

<aggi>so, i've deactivated mentioned musl-libc patch (i guess that was needed for fiwix kernel?), and nptl does work too, with linux-2.4

<Frans>@sh4: I had not seen it, but I heard about at WHY2025 (in August) from someone from NLNet. And some one commented about it when I submitted the project on HN. I should write something about this and some of the other approaches on my blog. I have just been reading through the master thesis. Looks very solid. (I do understand a bit of French, just

<Frans>enough to understand his acknowledgments section.)

<aggi>the nptl corner case is relevant, because it indicates a notable amount of ebuilds ported onto linux2/tinycc may to be ported onto fiwix kernel (given this hasn't got nptl)

<aggi>sata/ahci is stable now with linux-2.4 too, only added some pci_vendor_ids, 260MiB/s is a tad bit faster than ~10MiB/s available with usb2/flash-discs before

<aggi>sys_sync syscall deadlocked kernel with /bin/sync, didn't know why; no clue, i've mounted a few ramfs -o sync which caused this - no more deadlocks with sync()

<aggi>which means, linux/tcc kernel got decent hardware support now, it's been runtime tested extensively, including the gigantic nptl patchset applied

<aggi>i've tested nptl with unsquashfs only, seems working

<aggi>i suspect there's a bug remaining inside tinycc itself, detected when linking kernel; at least a workaround exists

<aggi>finally, i may move my entire main development-box (irc/mail/etc) onto linux-2.4 for further runtime-testing

<aggi>it's an almost identical userspace system-profile, ported onto both linux5 and linux2

<aggi>from the user perspective swapping kernel version abi is mostly transparent

<aggi>i am a little concerned about this one suspected tinycc-bug revealed when linking kernel

<aggi> https://lists.gnu.org/archive/html/tinycc-devel/2026-01/msg00007.html

<matrix_bridge><Jeremiah Orians> Frans: The minimal kaem optional just supports program name to execute followed by the argument strings. Exec is an optional optimization. Environment variables are not needed until we make the more complete C version of kaem.

<stikonas>Hi Frans. Welcome. A few of us here saw your talk

<aggi>almost missed that, besides pnut-sh there's another approach for an intermediate compiler which could spawn tinycc

<aggi>i'm a little concerned over potential instabilities with tinycc itself (given it's importance)

<aggi>and bootstrappable utilizes different versions/branches of tinycc, which would complicate bisecting against latest master/HEAD

<aggi>if, for example, some linking-related issue was/is persistent accross all of those versions, or got introduced on master/HEAD

<aggi>it's probably not too critical, if bootstrappable chains is stable with the branches/versions chosen

<aggi>so far, could isolate the issue being related to linking kernel with tinycc, which seems to cause runtime memory corruption

<aggi>which too could be related to tinycc compiled/linked bash5.static bug that i was hunting for month

<aggi>and this raises another question, if bootstrappable could/should (i got no opinion on this, there's pros and cons), to rebase bootstrapping patches for tinycc with latest master/HEAD version of it

<aggi>of cause, bootstrappable may need to re-compile tinycc itself several times, question is if it could/should be different versions/branches of tinycc each

<aggi>it's lastest master/HEAD seems sufficiently stable again, to drive tccboot/linux-tcc kernel, that's the one receiving most compile-time _and_ runtime testing i guess

<Frans>@aggi: At the moment, I am targetting tcc-0.9.26 like in live-bootstrap. My hope is that I can build a version of tcc that is exactly the same as the one produced by current stage0 of live-bootstrap.

<Frans>I have not succeeded in doing this, but maybe it only because I am not building the tools in a chroot environment.

<Frans>I see my work at complementary not competing with live-bootstrap. It will be a lot of work to get at the same level. I am also not aiming at the smallest possible seeds, but at 'easier' to review seeds.

<aggi>sorry Frans, didn't mean to be impolite, although i was interrupting your presentation :(

<aggi>it's just, i am concerned about tinycc instabilities/bugs disclosed, again

<Frans>stikonas: Thanks for the welcome. Nice to hear that some saw the presentation. aggi: That is okay. I think your work is also interesting. I am going to look into it. I am going to bed soon.

IRC channel logs

2026-01-11.log