IRC channel logs
2026-01-28.log
back to list of logs
<jackdk>What's the state-of-the-art among language choices these days? If I want to write something that has a moderately short bootstrap chain, am I still best served with c99 or is something like https://codeberg.org/ziglang/zig-bootstrap good enough that I can use it? <mwette>mes team: I think the new CPP for nyacc's c99 is working (i.e., works <mwette>with prev reported bugs and will parse gtk2 headers + dep's). See branch dev-3.03 in my repo. <lanodan>Zig sadly does not bootstraps from full-source, they use a wasm binary of the compiler as a seed, see zig/stage1/zig1.wasm in zig-bootstrap <lanodan>Typical recommendation would be more like: C (any version, although C23 is rather recent and C99 is the most widely supported), Lua, Go, C++, … <janneke>mwette: and ack on the use-module/include-from path hint <aggi>meanwhile thinking real hard, NPTL again <aggi>it's a miracle almost musl-libc doesn't clash with fiwix and/or linux-2.4 abi <aggi>by coincidence i guess, some related libc functions aren't called by anything required for bootstrapping and/or the self-hosting recompilation of the tinycc/linux system <aggi>even extensive runtime testing passed, since i moved my main development host onto tinycc/linux-2.4 into production <aggi>but, as soon as there is some pthread codepaths hit, sigh <aggi>another miracle, some runtime testing with net-vpn/tor.static here which does rely upon nptl, it's fully functional still atop linux-2.4 sysv abi patched for nptl <aggi>i don't know, how many places else some runtime ENOSYS or EINVAL are hiding <aggi>since i've sanitized sys-libs/musl for linux-2.4 - removing headers etc. - to hit compile time errors instead of runtime ones <aggi>i'm thinking real hard currently, if i did a test run with $ rm -f pthread.h then seeing which userspace parts actually pull this header <aggi>because, with either fiwix or linux-2.4 musl-libc does expose pthread.h and/or syscalls which are either absent (fiwix) or unstable (linux2) <aggi>compilation and linking pass, but inappropriate run-time behaviour must be expected, which is difficult to spot (runtime strace) <lanodan>Ah yeah forgot that one due to the horrible amount of steps required <janneke>lanodan: agreed, in the sense that the zig developers/community (still) haven't taken responsibility for their bootstrap story <janneke>although a similar thing can be said for gcc (think riscv, for example) <jackdk>I would love to use Zig but yeah that's tragic. Go is not at the right level for the sort of thing I'm targeting, and all the other "systems languages" seem even gnarlier <aggi>sorry, didn't mean to interrupt the zig related conversation <aggi>so far, with some more patching to musl-libc-1.1.24 ntpl seems to behave now (no more 100% cpu load anomalies for example) <aggi>hence a bootstrappable linux2 kernel besides extended hardware support could provide just that too, sufficient nptl support <lanodan>Well at least gcc bootstrap on riscv there's few versions to care about so backporting/forking is realistic, while for zig (and even more due to LLVM) it's not <matrix_bridge><Andrius Štikonas> it's based on steps discovered by Motiejus Jakštys but goes further to newer zig (follows guix steps too) <jackdk>Andrius: Thanks for the tip. That's a bit more convoluted than I would've liked, because then you need old llvm etc. Hopefully once Zig's self-hosted codegen matures, someone makes a good direct bootstrap. I think I'll stick with C99 in the meantime <aggi>out of curiosity, with any of the llvm-based language frontends (zig, rust) these rely on specific llvm backend versions too <stikonas>well, usually they support a few llvm versions <stikonas>that rustc redesign wouldn't change change much for our use of "bootstrapping" except that mrustc has to be used for std library too <stikonas>but I think we already had to do that anyway <stikonas>because rustc itself depends on std library too <stikonas>llvm is trivially bootstrappable from GCC though <aggi>it's probably no secret i'm praising the tinycc/linux/c-only system here almost each day, nonetheless i do admire your stamina and contenance <aggi>all else i rather shout into the pillow on my bed <Googulator>mwette: does this mean we no longer need to regenerate tables when bootstrapping mes? <mwette>Googulator: Yes, no more mach.d/* files: you will be pulling in tables from compiled mach.scm via use-modules. <mwette>I didn't know. I can update that as well. <Googulator>I don't know personally, as nyacc is used as a dependency of mescc <mwette>OK. cxeval is covered as well now. Thanks for catching that. <stikonas>Googulator: so I guess now we can completely skip that regeneration step? <Googulator>yes, it seems - assuming Mes can handle this new version of nyacc <stikonas>janneke: do you know if mes needs updating for nyacc 3.03? <janneke>for mes...but the cpp tree might just have minor changes, dunno <janneke>in that case, yes we'd need mescc patches <mwette>Just for kicks I'm seeing if I can code up a simple-match for the stuff that just uses define-macro. <FransFaase>Yesterday, I succeeded in compiling the tcc-0.9.26 sources with the compiler I have developed into an executable that is equal (to the last bit) as the tcc-0.9.26 executable build by live-bootstrap using the GNU Mes compiler. For instruction see the Task 1 section in the readme with https://github.com/FransFaase/MES-replacement <FransFaase>On https://www.iwriteiam.nl/D2601.html#27 I have published a T-diagram (based on the output of a strace commando) that shows the 57 processes needed to build tcc-boot0. This does not include all the additional executables that are build in stage0, which for example, are used to unpack the Tiny C Sources. The number of processes is substantial lower <FransFaase>than the 732 processes that are used in live-bootstrap to arrive at tcc-boot0. <FransFaase>These two tcc-boot0 executables are not the same, I guess because GNU Mes has support for 64-bit integers, where my compiler does not.