IRC channel logs

<aggi>so, i've glued some old linux-2.2 bootsect.S related pieces into linux-2.4, a little patching, as86 emits objects, vmlinux/bootable.iso

<aggi>errr....

<aggi>thing is, as86 was used by linux for a long time, and it is MUCH smaller than gnu-as

<aggi>not sure yet how much pain i'm willing to take to make this work again (since the gnu-as kernel does boot just fine)

<aggi>and when re-integrating TinyCC/OS with live-bootstrap as86 would shrink the dependency graph dramatically

<aggi>i do see, live-bootstrap/steps/binutils does rely upon autotools just like the ebuild i got

<aggi>with as86 instead this gigantic dependency graph of binutils/autotools to process very little bootcode.S pieces could be moved into a far later stage

<aggi>where it belongs, GNU toolchain bootstrapping can be separated from spawning a fully capable development host

<aggi>and currently it is those very few bootcode.S pieces ONLY which block this approach

<aggi>although it compiled/linked, it does not yet work, have to diff/bisect a few more things between linux-2.2/2.4

<aggi>and SMP-support could remain blocked, due to trampoline.S (as86 emits an incompatible object format which tcc cannot link into kernel image, not yet)

<aggi>but a non-SMP setup should suffice for the minified TinyCC/OS variant, which then can bootstrap binutils easily

<aggi>so, first i'll get going the non-SMP kernel with AS86 bootcode.S pieces, i hope, it should work since linux-2.2 did support this

<aggi>one more cigarette, then i'll go to bed

<aggi>ok, seems i got a bootable tinycc-linux2.4 with as86 bootcode.S pieces glued into...

<aggi>this means, TinyCC/OS can be re-integrated with live-bootstrap, without gcc/binutils/autotools/perl to spawn a complete development host with

<aggi>instead of binutils/gcc/linux4 the live-bootstrap fork will contain as86/linux2.4 then

<aggi>i really hope this will work as planned

<aggi>tomorrow i'll see to an as86 assembled trampoline.o can be linked into kernel, then SMP would work too

<aggi>although that's no blocker hence not urgen

<aggi>t

<aggi>best way would be tinycc supported 16bit real-mode, but the diffs i've seen for this were scary, and probably the reason why tinycc-devel removed those long time ago

<aggi>another major caveat in this context, i486-softfloat, which tinycc failed processing the related 32bit assembly pieces

<aggi>in case anyone ever had the crazy idea to spawn some bootstrap on i486-softloat, which free/open hardware FPGA deployment exists for (ao486)

<aggi>which i recall had been some dispute among LKML and torvalds, who argued such belonged into a museum anyway

<aggi>it's a long way to go for some free/open hardware involved with bootstrapping

<aggi>i've not had a look at fiwix yet, if that needs hardfloat and/or if it is gnu-as driving softfloat there, or if tinycc could do it

<aggi>a disadvantage of as86, of cause, it's x86 exclusive intel syntax

<aggi>which means the binutils integration with live-bootstrap must remain for a future prospect with riscv64 or whatever elese

<aggi>but for x86 it's a clever hack to shrink the dependency graph by dozens of millions of lines of code

<aggi>furthermore, it's trivial to keep both options for linux-tcc Kbuild, as86 intel syntax bootcode and gnu-as one

<aggi>maybe i'll have a look at tinycc 16bit asm again, but the #ifdef cascade was insane, and i think it finally just didn't work, and noone among tinycc-devel could tell if those dead/orphaned codepaths ever worked

<aggi>and i dislike the idea a little, as86 introduces a mix of different non-GNU syntax

<aggi>maybe there's something better, yasm

<aggi>which could more easily be detangled from autotools, supports gas syntax, and elf32 object output

<aggi>this is it, and yasm digested trampoline.S for SMP just fine without any further headache - kernel booted, going to bed

<aggi>strangely, yasm -p gas accepts trampoline.S but refuses bootsect.S, tricky

<janneke>mwette: ah, yes that's a newer smatch than i was using; the (? symbol?) match works now also with mes

<janneke>mwette: we'll probably use your smatch as (ice-9 match) in a future release, so what you're doing now with cond-expand in 3.03 is very nice until we have a release!

<aggi>ok, there's three assemblers now to support linux-tcc bootcode with: as86 (without smp), yasm (with smp), and of cause gnu-as

<aggi>as86 already is detangled form autotools, yasm can easily be detangled form autotools, and gnu-as remains optional

<aggi>this fully unblocks to proceed with live-bootstrap and shrinking the dependency graph for it by dozens of millions of lines of code

<mwette>janneke: OK, for 3.03.1 I'll code so mes uses (ice-9 match). I could make a release soon, if it helps.

<janneke>mwette: possibly not so soon! i'll be releasing 0.27.2 some time in march and it won't have your match yet

<mwette>Got it.

<janneke><3

<mwette>the smatch.scm in 3.03.0 has a lambda on line 57 that could be changed to a let if that makes it faster. -- i.e, `(let ((,pat ,exp)) ,kt)' instead of `((lambda (,pat) ,kt) ,exp)'

<ekaitz>mwette: just talking without all the needed context here so this might be stupid but doesn't the let expand to the lambda in Mes?

<aggi>maybe one of the most relevant insights:

<aggi>there is no standard at all for assembly language programming itself even when there is a level of abstraction above hardware-specifics

<aggi>i think that is one reason why Linux-Kernel fully transitioned to GNU-toolchain (linux-2.2 -> linux-2.4 at that time), since there gnu-as at least followed a somewhat consistent assembler macro-syntax

<aggi>with the tradeoff binutils introduced a gigantic dependency graph to process some tiny little 16bit real-mode asm "only"

<aggi>and this gigantic dependency graph is unavoidable almost, because GNU was forced into a dozen layers of abstractions for portability

<aggi>assembly language programming should have followed some standardization from the beginning

<aggi>for that matter i too recall a little Verilog/VHDL from my studies (after all Telekom University had been a sales marketing outlet of the industry), down there situation is horrifying likewise

<aggi>glory hallelujah, a few levels of abstraction above, C-language did remain mostly stable for almost 40years

<aggi>but nowadays, that's too destabilized by "improvements" made

<aggi>btw. yasm does showcase a proof-of-concept, with it's internal implementation there is a layer of abstraction for assembler macro syntax variants

<aggi>that's how it can process different of these: nasm, tasm, gnu-as, at the language frontent

<aggi>*frontend, this to means standardization was feasible there

<aggi>and i do think it too would have been possible for the hardware-related backend side, for decades already

<aggi>from a practical standpoint, finally, it's a major pain with bootstrapping dependency chain

<aggi>without standardization followed binutils pull in a gigantic dependency graph for tiny little 16bit real mode boot code

<aggi>this week i've seen a video on youtube, when Torvalds began ranting about RISC-V (who couldn't agree upon some bswap implementation and LE/BE support, hence intend to clutter kernel with #ifdef cascades for this, again)

<aggi>sadly, his position to argue is weak, since linux had accepted far too much of this for decades, blowing up it's codebase 100fold in recent decades

<aggi>$ man gcc; that's a hundred pages documenting support for proprietary extensions too

<aggi>for that matter, i've never played with LISP/Scheme, since i fear that's fragemented likewise

<aggi>and to my understanding that's the approach of live-bootstrap, another layer of abstraction with scheme to implement mescc

<malina>he. and linux.org also promised they would revel the attack on their serve rwhich they ever did, which is basedon sha1.. so you know.. enough said...

<malina>nsa have that covered along time

<malina>sadly form being free thinking fin, he has become a qute standard yank

<malina>quite

<malina>not very trustworthy

<malina>it is what it is, design accordingly

<malina>I was banned here from your yank oransj, who banmed my ipswhich had no relevance ot here, showing that either we can't trust libera admins or him, either way. I spoke of higher forms of freedoem, not popular with yanks, I am sure. always think about wat is right, ot what is told to you what is right

<malina>imo. but ye. hey. you guys do you.

<malina>on the plus side, one ignored the bs, like "oh it's all gpl, and yet half of it is from ppl who were more genersous and so on in the sources... who would have known... I run my main musl os based on this though

<malina>I have to cross fro i286 to amd64 for the musl ironically but ok. no biggie

<malina>there almost seems to be this fancy wisdom is invertely proportonial to knowledge in the world, which I always found amusing but prolly why I don't really get humans, even if I was so "accruable to others", don't worry not here. don't wanna get the ignorant all worked up, after all

<malina>so ye, linus runs the largest sw projec tin thw world and does it fantastically well, but, trusting him these days is way, way less reliable

<malina>he live sin a noe-nazi country at th end of the day

<malina>which oppsoes such work as this a such

<aggi>the as86 trampoline.S port is falling apart with ljmpl, i'll just leave that commented on TODO

<aggi>it's several aspects, if/where/how 16bit real-mode got implemented

<aggi>i'll try to integrate the combination of yasm with tcc-toolchain for this, since this will suffice for SMP support from the beginning

<aggi>but, since tinycc is missing the 16bit assembly pieces alltogether (to my limited knowledge), the JiT/tccboot approach remains blocked indefinitely

<aggi>which was the idea of tinycc from the beginning, to spawn/bootstrap some linux JiT with tccboot

<aggi>there's a circular dependency remaining anyway, since tinycc hasn't got 16bit pieces, with or without the desire for SMP

<aggi>some ACPI-codepath too needs ljmpl with 16bit assembly

<aggi>but this codepath is optional, not needed

<aggi>after all, SMP was slightly interdependent with ACPI, except for some earier implementation available with, guess what, linux-tcc 2.4 kernel

<aggi>*earlier

<aggi>so, the only disadvantage of replacing binutils with yasm, the latter doesn't offer a JiT tccboot system-integration, as86 doesn't, and gnu-as doesn't, that's all AoT (or not "bootstrappable" hence)

IRC channel logs

2026-02-27.log