IRC channel logs
2026-09-24.log
back to list of logs
<notgull>How hard would it be to make it so Fiwix can be launched as a UEFI executable? <aggi>mwette> The full C preprocessor is a bitch to implement <aggi>as a side note: while confirming a complete package set against tinycc i've stumbled upon <aggi>nfs-utils/rpcgen, a rare occasion, even tinycc c preprocessor failed with <aggi>i've pulled into mcpp for that reason, to retain NFS support <aggi>with regards to minimal C / macros, obviously the criterion is what a c-compiler implemented in assembly could support <aggi>from a practical perspective currently that is cc_x86 <nikolar>what's so gnarly about nfs-utils/rpcgen <aggi>next one is pnut-cc which cc_x86 can compile, and then finally tinycc had to restrict it's internal language feature set again <aggi>which is what laurenth documented <aggi>nikolar: to be precise among gentoo it's two ebuilds <aggi>net-fs/nfsutils and net-libs/rpcsvc-proto <aggi>i think tcc -E merely produced empty headers (in conjunction with rpcgen), which did not match what nfs-utils expected for functional NFS support <aggi>since i seeked to confirm a complete *nix package set _without_ gcc/binutils/llvm/clang i merely utilized mcpp as a workaround <aggi>anyway, that's only some boring details from the system-integration perspective of tinycc/OS <aggi>NFS was remarkable in this context, because it's a crucial Unix component, which wasn't trivial to retain with linux-tcc and tcc-toolchain <aggi>net-fs/bind9 was another such remarkable piece, when remaining conservative with C-standard followed <aggi>in this case, since recently, it needs C11/23 __thread extension <aggi>without such critical standard internet protocol service and utilities are lost, so i've blocked bind9 at some older version (year 2022) which remained mostly C90 compliant <aggi>recently there's been a lengthy discussion on tinycc-devel to implement __thread extension <aggi>however, that's the good news i think: it's not necessary still, a complete *nix system profile (including kernel, libc, userspace) for a fully functional development host can be re-integrated _without_ such <aggi>hence C99 _Complex (another lengthy discussion), __thread and various other extensions can remain optional <aggi>and remaining conservative with C standard followed for long-term stability (C90 that is >35years) is justified for the sake of it's own <aggi>interesting, english wikipedia mentions C89/90 ANSI/ISO standards were withdrawn <aggi>which isn't plausible on a technical basis, because later standard iterations - to my knowledge - merely defined non-conflicting extensions <aggi>that means referring to ANSI C, by definition, _excludes_ C89/90 and implies later iterations _only_ with some undesirable extensions then <aggi>because those are non-optional (_Complex, _Generic, __thread etc. etc.), although those extensions should remain optional for the sake of long-term stability, and bootstrapping of cause <aggi>from a practical perspective, this reminds me of yet another critical component: dev-libs/elfutils (from IBM/RedHat (R) ) <aggi>just as said, i verified a complete *nix system-integration _without_ gcc/binutils/llvm/clang, and checked elfutils hence <aggi>again, guess what, i've had to pick a rather old 0.127 version of it from the archives, because later versions utilized __thread extension iirc, and could not be bootstrapped/compiled by an ANSI C compliant toolchain (such as tinycc) anymore <aggi>the reason why i've quit with Linux kernel updates and hacking too was related to ANSI C infringements, in this case since linux-5.7 it's been _Generic macro introduced since then (among other issues) <aggi>which then is biting linux-tcc kernel with POSIX 99 standard (time64 mainly y2038, timer subsystem such as CLOCK_MONOTONIC, and a few other less critical) <aggi>good news in this case, it's been possible still to remain conservative with POSIX too, while retaining mentioned portable *nix system profile <AwesomeAdam54321>sneek, later tell notgull: I don't know for sure, but I think the adjustments would be similiar to what is done in stage0-uefi <matrix_bridge><Andrius Štikonas> And we still need to fix posix-runner to do steps between mes-m2 and fiwix <matrix_bridge><Andrius Štikonas> Which needs at least implementing memory mapping <mihi>I don't think it is technically necessary for Fiwix to be 64-bit to be able to "just" launch it from an UEFI binary. 32-bit Linux can also be launched from 64-bit UEFI. You would need a multiboot stub similar to e.g. Limine that loads fiwix into memory, switch to 32-bit mode and run it. I think the bigger problem would be hardware support, I don't know how many UEFI machines exist that still have IDE/PATA drives <mihi>and PS/2 keyboards and mice. And I doubt Fiwix supports SATA or AHCI or USB. Maybe even VGA console may be a limit, but maybe EFI GOP Framebuffer would technically work. <nikolar>you can probably get ps2 peripherals through the uefi/bios emulation <mihi>I would expect them to cease working once ExitBootServices is called, and without calling it you cannot reliably switch to 32-bit mode. <mihi>If a machine has a CSM, I don't see the need to boot Fiwix via UEFI, to be honest :) <mihi>In fact (mildly off-topic), about half a year ago I helped some customer install W32-bit in7 on a fairly recent machine, and even the USB2 emulation for the USB3 ports stopped working once 32-bit Windows was booted. So the way to go was to find XHCI drivers and slipstream them into the Win7 setup. <aggi>with linux-tcc (coreboot/seabios real-mode boot), i got confirmed USB1/2 only; good point, it's critical if not at least peripheral I/O was guaranteed to remain and XHCI (plus firmware blobs for this) was necessary _always_ <aggi>most hardware is obsolete already (https://15h.org for AMD bulldozer coreboot support mentions some) <aggi>at least i could confirm coreboot was mostly trivial to test/port for FM2 boards, and those are easily dumpster dived for on ebay <aggi>with a few driver backports to linux-tcc (gigabit ethernet, usb2-ethernet, sata/ahci) there is some practically useful system remaining <aggi>even when that's x86_32/16 only, at least there is something remaining to work with <aggi>interestingly, those fm2 boards too run with win7-64 just fine, even with coreboot, latest linux5/6, linux-2.4 (which required some coreboot patches for BIOS IRQ assignments) <aggi>win10 too was known to work (although i don't bother with this) <aggi>vesa-framebuffer, 16GiB RAM (when PAE mode is activated), usb3 ports work as usb2 without firmware blobs; only bad news is this era has ended with UEFI <aggi>and it's a long way to go for RISC-V to arrive anywhere close to what x86_32 already offers already <aggi>i was reading, even among Intel it's been their Intel Galileo x86_32 subsystem that powers their IntelME <aggi>yet Intel too chose to phase out their Galileo boards <aggi>latest AMD (suceeding FM2/bullodzer), nowadays are quipped with their PSP, which is the _main_ CPU, and this is a blobbed ARM one <aggi>so, for those, this first required reverse-engineering and/or overhauling the whole, well, ARM bootstrapp <aggi>which too is an intersting aspect, to retain some fully bootstrapped system, for latest AMD Ryzen (and similar issues among Intel) <aggi>this needs at least TWO complete system-bootstraps: the one for x86_32/16, plus ARM, and dependening on CSM stage0-uefi as a third <aggi>to retain a working system, which the "legacy" x86_32/16 systems required only one such system-bootstrap for one ARCH <matrix_bridge><Andrius Štikonas> Almost surely they are signed at hw level <ekaitz>stikonas: I found some other M2 trick <stikonas>yeah, I briefly looked on Sunday, but didn't manage to fix it <ekaitz> if (fn->type == TBUILTIN && builtin_arity_ (fn) == -1) // this doesn't work <stikonas>if (A && B) also doesn't short-circuit in M2-Planet <ekaitz>i guess || doesn't shortcircuit either, right? <ekaitz>i have a garbage collection issue in M2 that doesn't appear in GCC <stikonas>hopefully it is reproducible with GCC compiled M2-Planet <stikonas>hmm, though I guess you need to debug mes not M2-Planet <ekaitz>any other weirdness I should be aware of? <ekaitz>okay so I made some harmless changes and I broke everything even for gcc <ekaitz>a very interesting night I'm going to have I think <ekaitz>stikonas: sizeof an enum? what do you say about that? <stikonas>it should always be 64/32 bits type I guess <ekaitz>i'm having an issue with the gc and I see the garbage collected cells be 16 bytes away one from another <ekaitz>yep it's basically wrong the sizeof <ekaitz>stikonas: in mes master says the struct size is 12, in my code says 16 and using gcc it's 24 <ekaitz>but maybe the error is not related with that