IRC channel logs
2026-06-06.log
back to list of logs
<roconnor>Cue the Oprah meme because my bracket abstraction has generated 19738 B's. <xentrac>should it possibly be using B* or something to avoid an exponential blowup? I remember I had this problem when I wrote a λ-calculus to S/K/I/B/C combinators compiler <xentrac>19738 sounds suspiciously close to 3⁹ <roconnor>potentially. I'm planning to move to Oleg's better bracket abstraction once I get a slightly further along my compiler quest. And ultimately the compiler just generates a graph directly as a table in the executable file instead of relying on combinators to build the graph from a tree. <roconnor>bracket abstraction is apparently the name for converting lambda exprssions (and combinators) to pure combinators. <roconnor>or rather converting one lambda to combinators. <roconnor>There are a variety of methods and with a variety of target combinator sets. <roconnor>of course any complete set is within a constant factor of any other complete set. <xentrac>you've probably read the same SimonPJ book I was reading <xentrac>huh, I didn't realize I did that in 02006. I thought it was several years later <xentrac>looks like I was using S, K, I, B, C, B*, C', and S' <roconnor>yeah, I recently looked at that chapter from his book. <xentrac>IIRC I did experience and defeat the exponential blowup you're facing (19738 is 19683 plus 0.3%, so I'm reasonably confident that that's where it's coming from) just by following the instructions in that chapter <roconnor>I didn't actually read this page yet. I read Oleg's paper, which I found difficult to follow, though I eventually made it. <roconnor>I'll be curious to see how much it improves things. <siraben>Yeah I found Oleg's paper a bit difficult to follow as well. and I'm not familiar with OCaml being used like that, tagless-final style. <siraben>but broadly, the idea is "what if you interpreted lambda terms and kept track of their De Bruijn environments, then use that information to select for combinators more efficiently?" <roconnor>yeah. Oleg phrases it in terms of De Bruijn indices, but I'm comfident that I can work with just a nomal environment from names to "values", for Oleg's special notion of values. <xentrac>I often find Oleg's papers difficult to follow, but generally I think it's because the concepts he's explaining are inherently difficult, not because he explains them badly <xentrac>I was satisfied just to get the λ-expressions translated to Schönfinkel combinators without any exponential blowups in the expression size <xentrac>the the point that I didn't worry about the efficiency of the compiler <xentrac>there are many differences between me and Oleg, but I think that this is one of the big ones <aggi>back to qemu for a moment, as a test-host for aarch64/riscv, since their support appears on the horizon (gladly) <aggi>to my understanding a key aspect of bootstrapping is keeping complexity reasonably low whenever possible <aggi>and not blindly using any tool, runtime or development environment blindly <aggi>without consideration how this would impact bootstrapping with a "circular dependency" <aggi>as said before, it's not a practical concern, just in case any aarch64/riscv system was booted on qemu for testing <aggi>in theory however, qemu itself should be bootstrapped before it's relied upon <aggi>since the current situation is, the whole x86_32 bootstrap remains to arrive at a qemu-host anyway <aggi>the reasoning then was, to re-integrate any qemu version as configurator/steps build into the x86_32 bootstrap <aggi>and keeping the x86_32 bootstrap itself as a preceeding dependency for aarch64/riscv as small as possible <aggi>in the end, if the whole complexity for a riscv/aarch64 bootstrap was unavoidable with qemu involved (which it is in practice almost always) <aggi>i tend to think keeping it at cross-toolchain maintenance for those ARCH remains a practical solution alike <aggi>otherwise, of cause, bootstrapping those beginning at stage0 are an engineering discipline in it's own right <aggi>out of curiosity, which testing-targets (real hardware other than a qemu host) is the favorite choice for aarch64/riscv bootstrapping? <aggi>ok, with visionfive2 that's a u-boot + linux5/6 system like many other aarch64 did before <aggi>which then leaves u-boot to an open discussion, on the software side, as a preceeding dependency to a stage0 bootstrap <aggi>not much different to the coreboot/seabios one on the x86 side - the need for a c-toolchain before that got bootstrapped <aggi>don't know yet if there's an ATF equivalent with the visionfive2 <aggi>meaning this, such aarch64/riscv variants are trustworthy more or less, free/opensource, but not fully bootstrapped even with a complete implementation of stage0 up to linux5/6 kernel <alganet>aggi: likely right. Until I buy some riscv64 and aarch64 boards and test them on real hardware, it will still be a prototype. I made those kernels firmware-independent though (stage2), so another stage1 for them could be developed for non-qemu or other real hardware. <alganet>aggi: regarding qemu-independence, I had the same thought as you and started to work on a project called bemu: https://github.com/alganet/bemu It's an emulator that compiles only with stage0 dependencies (very early stage, already self-hosts, but likely too slow still) <alganet>It's a test dependency of some sort (given the real hardware horizon), but often neglected, which can create a risk scenario (letting too much work be delegated to this testing-dependency layer) <alganet>buying a riscv64 board in Brazil (where I am) is practically impossible, I found none. Raspberry is easier, but I doubt one could get far in bootstrapping in reasonable time <aggi>yep, a whole other practical aspect of this, long-term availability of any such SBC, and price (typically i order at least two boards to have one spare always) <aggi>currently i can't find any trader in germany remaining which would ship rock64 (that's the one i played with for a while) <alganet>For aarch64, a realistic bootstrap target in that angle are macs. Likely to have tons around for people to use in the foreseable future. Also, full of proprietary opaque firmware which complicates things. <alganet>I don't know rock64, but during development I was tempted to go for nvme for disk. It would simplify a lot of things (also, a standard of sorts instead of sd/mmc nightmare). But those are even more expensive to import here (a powerful riscv64 board with nvme storage) <aggi>while ago rock64 with a quadcore aarch64 shipped for $30 here (1GiB RAM), and a little more for the 4GiB RAM <aggi>and pine64.org advertized a few offerings as "long term supply" <aggi>what kept me going with aarch64 for a while: much lower electricity consumption when such a thing is running 24/7 compiling things <aggi>electricity is insanely expensive nowadays in germany (last time i checked it's been 60cents/kWh) <aggi>and the coreboot/fm2 system (which i prefer now for there great computing power) soak >50Watts+ - 10fold the amount of aarch64 <alganet>I would say 2GB is the minimum for how this line of bootstrap works today (builder-hex0 has a in-memory filesystem, and never clears memory until fiwix/next-kernel (all for simplicity), so it will always need huge RAM. For a complete live-bootstrap 4GB is the bare minimum). <aggi>well, except for the statically linked ffmpeg/mplayer build which hit OOM (with tinycc, outside the scope of bootstrappable), i easily managed with 1GiB RAM <aggi>compiling gcc/g++ was another trouble-maker with 4GiB RAM available even <aggi>so, yes, keeping this in the 32bit envelop is something else to think of <aggi>because, as soon as developers got more RAM, they're throwing all sorts of bloatware at it <alganet>lot's of things to consider, it's not just how much memory the compiler uses. For example, in live-bootstrap builder-hex0 has to load all distfiles into RAM, so it can build the fiwix ext4 disk (which is also loaded to memory), before it can clear ram for the first time. It's a wasteful design, but simplifies a lot of things. <alganet>I followed the same idea, because honestly not doing it would make these first kernels immense <stikonas>ATF is arm stuff, riscv comes with opensbi <stikonas>and to be honest, for expensive electricity germans have to blame themselves and their politics. It was stupid to ban nuclear energy <aggi>ironically it's been the civilian use banned - meanwhile there's nuclear weapons stockpiles in some places remaining, and waste <stikonas>in uk average electrity price is maybe 30 euro cents or so <stikonas>though you can get better deals if you can shift your usage or have house battery <alganet>in this regard I'm kinda blessed, Brazil's electricity is cheap and abundant and no need to use it for heating. I could easily afford having a server-like machine running 24/7 at home <alganet>in fact, many brazillians do (use refurbished high-wattage xeons as PCs) <deesix>aggi: you keep saying things like """outside the scope of bootstrappable""". You keep ignoring that there is no single "bootstrappable" thing, at all. Stop doing that, for good, please!