IRC channel logs

<roconnor>I've been hoping to integrate it within https://github.com/roconnor/nixpkgs-bootstrap/ , which it itself 3 years old.

<roconnor>The problem is that my particular version of M2-Planet doesn't like the malloc declaration:

<roconnor>void *malloc(unsigned long);

<roconnor>heh. I have this sneaking suspicion that this only worked in the past because M2-Planed used to parse that "long" as a variable name.

<roconnor>*M2-Planet

<roconnor>Anyhow, this should be easy enough to patch

<roconnor>Actually the lastest M2-Planet does seem to support multi token primitive types, so updating would probably also work.

<siraben>roconnor: what do you think about how much complexity I should put into the C compiler in Haskell?

<siraben>I'm considering doing proper register allocation, but it's not _blocking_ per se

<siraben>it's 6.6k LOC of Haskell right now

<siraben>Actually I'm thinking next steps is just to get the bootstrap path working for aarch64, i386, riscv potentially as well.

<roconnor>is 6.6k a lot?

<roconnor><siraben> hcc path to self-hosting TCC is 7m56s vs. 4m31s for MesCC

<roconnor>I was going to say that at least the hcc path has less source code.

<roconnor>... presumably

<siraben>yeah, but at present hcc is overfit to tcc, doesn't support anything tcc doesn't use

<siraben>and there's like 3k LOC for C support for HCC, so total around 10k

<roconnor>well IMHO it's better to for the bootstrap if your C implementation is simple, slow and correct rather than fancy, fast and erronous.

<siraben>A big advantage here over mescc is that the parsing is done in Haskell not via nyacc

<siraben>So easier to audit

<xentrac>hi, long time no see

<xentrac>I was just fiddling around and saw that LCSC offers 74HC14 chips for 3.69¢ https://www.lcsc.com/product-detail/C51927315.html and 74HC08s for 4.22¢ https://www.lcsc.com/product-detail/C51927314.html

<xentrac>and I was wondering what the current status was on building CPUs out of discrete logic

<roconnor>I'm not qualified to answer, but you seen the Ben Eater's series on Youtube?

<xentrac>oh hi roconnor! it's Kragen

<xentrac>glad to see you!

<roconnor>Hey, New nick I see.

<xentrac>yes, or old one

<xentrac>I happen to be visiting the Bay Area at the moment and am disappointed to find that the bab5 list seems to have evaporated

<xentrac>what are you up to these days?

<roconnor>So I literally made my first ever digikey order of chips and breadboards and wires and stuff.

<xentrac>that's exciting! are you physically in Canada these days?

<roconnor>Yep

<xentrac>I probably won't be able to help you debug your circuits, then

<roconnor>So https://codeberg.org/interrupt_tv/steadyhand was posted here a few weeks ago.

<xentrac>I mean. I can't poke them with logic probes or anything

<roconnor>Which links to a much *much* simplier device that Ben Eater builds to program EEPROMs

<roconnor>in part of his series on making a *very* simple 8-bit computer out of logic gates (more or less).

<xentrac>seems reasonable

<roconnor>Anyhow the EEPROM programming device got me so excitted I bought said components and breadboards and whatnot.

<xentrac>that's wonderful :-)

<roconnor>So far I've make some blinking lights.

<xentrac>with a ripple-carry counter?

<roconnor>Now I'm struggling to get push buttons to work at least marginally reliably, which apparently is known to be somewhat hard.

<xentrac>yeah, debouncing was surprising to me when I first learned about it

<roconnor>I have a 8 bit shift register

<roconnor>and so I made a little LFSR, linear feedback shift register.

<xentrac>excellent! producing an M-sequence?

<roconnor>I don't know what that is. But I just used 4-bits because I was to lazy to hook it up and Gemini told me what bits to xor to make one of maximal length.

<roconnor>*too lazy to hook up more

<xentrac>yeah, an "M-sequence" is a maximal-length LFSR sequence

<xentrac>there were a few computers that used LFSRs for their program counters back in the 70s

<roconnor>lol that's what I was thinking they could be used for.

<xentrac>saves a few gates for program counter incrementation at the cost of complicating the assembler

<xentrac>sometimes only the low bits of the program counter were the LFSR, the high bits remaining constant

<xentrac>so you could LFSR-increment within a "page" but had to jump to get between "pages"

<xentrac>I feel like 8 bits makes the CPU kind of unnecessarily complex as an optimization to allow using cheaper PCBs and leadframes at the time (01978 or so)

<xentrac>because nobody had an 8-bit address space. all the 8-bitters used a 16-bit address space, which introduces all kinds of complications

<xentrac>and nobody had 8-bit instructions either. the maximal-length instruction was always at least 16 bits, with the possible exception of the 8008 and 4004 (I forget)

<roconnor>Another plan was to use the LFSR to clone circuits into an EEPROM.

<xentrac>12 bits, like the PDP-8 and the Patinho Feio, is a much more reasonable word size, and it gives you much simpler control logic

<xentrac>that will definitely work

<roconnor>work for all but one value.

<xentrac>you can special-case it :)

<xentrac>but it might be easier to just use a ripple counter

<xentrac>with T flip-flops or J-K flip-flops it's just as easy as an LFSR, just slower

<xentrac>I think that with these new LCSC prices it should be possible to get the price for a 12-bit CPU below US$10 of parts

<xentrac>and with D flip-flops you still only need a NOT gate per flip-flop

<roconnor>I learned about J-K flip-flops after I placed my order.

<roconnor> https://www.digikey.com/en/products/detail/stmicroelectronics/STM32C011J6M6/17078253 is 82¢

<roconnor>ARM® Cortex®-M0+

<xentrac>my Radio Shack science-fair electronics kit had a J-K flip-flop chip: https://www.reddit.com/r/electronics/comments/sgnd56/found_a_200_in_1_electronics_lab_kit_new_in_box/

<xentrac>if you're looking for a cheap Cortex-M0+ https://www.lcsc.com/product-detail/Microcontrollers-MCU-MPU-SOC_PUYA-PY32F002BD15S6TU_C7469097.html is 9.01¢

<xentrac>only 3K of RAM instead of 6K and 24K of Flash instead of 32K though

<roconnor>My point is that I think you have a CPU for less than $10. :)

<xentrac>oh, yeah, but the idea of building the CPU out of discrete logic is that you can audit it for backdoors

<xentrac>historically this was completely impractical because it would be really expensive

<xentrac>like I think the estimate for the MOnSter-6502 was that it cost about US$1000

<aggi>system management mode, SMI interrupts, that's the hint given by coreboot.org

<roconnor>Maybe, but what do you do with such a cpu? Presumably you need a chain that lead upto USB Mass Storage / nvme something something.

<aggi>in any case, it's a huge gap to bridge from some tiny 12bit CPU towards a bootstrappable platform init let's say for AMD FM2 type systems

<xentrac>Maybe. SD cards support SPI, which you can do on anything with two digital output pins of any spead

<xentrac>*speed

<aggi>for that matter, nowadays FM2 CPUs are cheap too, beginning at $5 plus mainboard for another $10 and a gig of ram

<xentrac>hard to audit though

<aggi>no doubt

<xentrac>the small CPU might be able to compare supposedly reproducible builds done on two or more different big computers to verify that they did in fact reproduce

<aggi>and even worse, the whole coreboot/SeaBIOS realm is not bootstrappable, it's a gigantic circular dependency graph

<xentrac>or verify a MetaMath proof of correctness of a secure kernel

<aggi>there's the ao486 SoC FPGA deployment available for x86, this too relies upon SeaBIOS, hence not bootstrappable

<aggi>with firmware covered

<aggi>in practice it's just not possible/feasible to bridge the gap from some 8bit/16bit breadboard computer towards x86

<xentrac>those cheap 74HC14 chips still have a 15-nanosecond propagation delay, so it's going to be hard to get a discrete-logic CPU that runs at 20MHz

<roconnor>xentrac: Did you read about https://www.bunniestudios.com/blog/2026/baochip-1x-a-mostly-open-22nm-soc-for-high-assurance-applications/

<xentrac>roconnor: yes! I've been finding it exciting

<xentrac>relevant bookmarks are on https://canonical.org/~kragen/human-folly/tag/baochip.html

<xentrac>or better http://canonical.org/~kragen/human-folly/tag/baochip.html

<xentrac>aggi: the purpose of building an auditable computer out of discrete logic would be to defend against possible hardware backdoors, and in most cases that threat model doesn't admit any possible defense when you're running on the hypothetically backdoored hardware

<xentrac>I mean it depends somewhat on the details of the threat model

<roconnor>good night

<xentrac>goodnight roconnor! I'm glad to see you

<xentrac>but if the threat model includes an adversary who is, for example, corrupting the output of compiler runs on your backdoored hardware, it seems like it doesn't really help to initially build the compiler and operating system on some other, non-backdoored hardware

<xentrac>regardless of anything about USB mass storage or SeaBIOS or coreboot

<xentrac>you just can't trust the results of any execution on the backdoored hardware unless you manage to do fully homomorphic encryption or something

<xentrac>there are a few exceptions. you could use the backdoored hardware to search for a proof of correctness which you then run through a verifier on the non-backdoored hardware

<aggi>xentrac: for the same reason i've ported coreboot/seabios to another AMD FM2 board recently

<aggi>hacked linux-2.4 kernel for tinycc-toolchain support, which by coincidence does run fine on such a system

<xentrac>nice!

<xentrac>congratulations!

<aggi>for that matter, almost all userspace parts running atop such are recent software versions too

<aggi>plan is to re-integrate this into live-bootstrap configurator/steps build/packaging system

<xentrac>that's fantastic!

<aggi>however, i cannot yet self-host/compile coreboot/seabios with tinycc/yasm

<xentrac>right

<aggi>and, that's the intersection with 16bit computing: real-mode ASM

<aggi>beginning with platform initialization

<aggi>i'm struck by some issues: isolinux/syslinux, and just as said firmware compilation

<aggi>even when coreboot/seabios could be compiled/assembled with tinycc/yasm, it's a build-time ciruclar dependency, hence not bootstrappable

<aggi>less of a sescurity concern, but a principle engineering one

<aggi>such an x86 system cannot fully be spawn from scratch including a firmware bootstrap

<xentrac>yeah. you maybe want to start with something like Oscar Toledo G.'s bootOS: https://www.youtube.com/watch?v=qaI0WvgTNCc

<xentrac>well no

<xentrac>I mean that still depends on BIOS

<aggi>exactly, good point

<aggi>rickmasters stage0 loader/kernel/macro-asm too does

<aggi>although it's a brilliant piece of thing, to get going live-bootstrap, most important pieces are just missing

<xentrac>but if you're willing to nail down the peripherals for your bootstrap path, they don't have to be any more complicated

<aggi>i see no realistic chance to hack into AMD AGESA to shrink that to something reasonable, to make that bootstrappable

<xentrac>like the STM32C011J6M6 roconnor mentioned

<xentrac>I mean it's a 48MHz RISC processor, faster than the SPARC 5 I used to have on my desk but with less RAM

<aggi>ok, there's many options, Gigatron TTL, Ben Eaters 8/16bit systems, but all this cannot yet bridge the gap towards x86 live-bootstrap

<xentrac>you could totally run an x86 assembler on it to build something like SeaBIOS from some kind of source

<xentrac>someone would have to write one

<aggi>sorry, i can't

<xentrac>no worries! you're doing a lot of awesome stuff already!

<siraben>added some basic peephole opts from the IR to M1

<roconnor>siraben: AFAIU the bootstrap process start with tcc building with mes's libc before eventually building musl. What does your proposal use?

<siraben>Added riscv and aarch64 support, going to merge those today

<siraben>roconnor: samw, just want to huild tcc get it to self host then the rest is the same

<siraben>s/samw/same

<siraben>Philosophically I wonder what people think of a stage that _lowers_ TCC into M2-Planet, rather than compiling TCC into M1

<siraben>old habits die hard, now making the shell scripts all use kaem so I can actually claim bootstrappability

<siraben>I still had a hidden CFG with ICond nodes, flattening it out now so the final IR → M1 lowering is linear

IRC channel logs

2026-05-11.log