IRC channel logs
2026-05-25.log
back to list of logs
<aggi>this is a key question, if a commanderX16 type system could bootstrap and host a C-compiler/assembler/cross-toolchain to target x86_32 (or any other modern system), then compiling kernel/bootloader/target-toolchain for such a system <aggi>another one was the hardware design and development utilities which must have existed in 1980s some time, used to design and develop x86_32 for example <aggi>an Altera Quartus, Xilinx etc. type IDE certainly doesn't fit into the 8/16bit/DOS realm <aggi>in other words, it seems almost impossible to escape the 8/16bit realm to arrive at something modern with a c-compiler to target 32bit <aggi>leave alone hardware development <aggi>another irony with this, it's been THE major argument made for Intel X86 IBM PC, "backwards compatibility" <aggi>meaning up until recently (predating UEFI), it's been possible almost always to boot some 16bit DOS floppy <aggi>from the hardware-development perspective it's even more challenging, even when there's a few opencores.org designs available <aggi>including some USB1.x, ethernet chips etc., some early ARM, MIPS and even X86_32 designs <aggi>but all of this relies upon a gigantic pile of tooling (Xilinx, Altera, Lattice) <aggi>something, again, which is remarkable, because in the days of 16bit DOS era such tooling was neither available nor necessary <aggi>there must have been hardware development tools running on DOS (and similar) <aggi>how's that called, "bitstream compiler", which processes Verilog/HDL <aggi>another concern, it's the typical measurement gear involved, digital scopes <aggi>analog scope manufacturers vanished (Rohde und Schwarz, Tectronix, this realm), they're all trapped <aggi>almost forgot, logic analizers <aggi>for that matter, sticking to the 10MHz (up to 100MHz) realm is far more cost-effective <aggi>but i dislike the idea in principle, the need to download gigabytes from Altera, Xilinx whoever <aggi>just to develop and deploy some 10Mhz 8/16bit system <aggi>KiCAD is another example for this, you couldn't design and print a PCB without hundreds of millions of lines of code for this <aggi>yet, how then did engineers design and print PCBs in 1980s DOS era? <aggi>reminds me of another story, german military dumped dozens of billions into their new "digital radio" system, which isn't combat ready <aggi>hence ministry decided to re-establish manufacturing of 1980s analog gear <xentrac>I don't think there's any point in entering the 8/16 bit realm in the first place. Just use ARM or RISC-V <xentrac>you don't need gigabytes from Altera or Xilinx to run yosys, nextpnr, and the rest of APIO <xentrac>and those are amply capable of synthesizing a SeRV bitstream for a Lattice FPGA and starting it running on the FPGA <xentrac>even in the 16-bit realm, though, there's nothing especially insane about running a 16-bit compiler that generates 32-bit code. I don't have one handy but you could write one in a few weeks if you wanted. But really I think 16-bit machines in the VLSI age were kind of a mistake. The 32-bit ARM 2 was 27000 transistors, the 32-bit 68000 was 68000 transistors, and the 16-bit Intel 286 was 134000 <xentrac>omitting the cache on the ARM 2 was also a mistake, and so were the wide instructions, probably, given that SeRV is a 32-bit RISC in under 9000 transistors, and Graeme Smecher's Minimax is about the same size but much faster by using only compressed instructions: https://github.com/gsmecher/minimax <xentrac>it handles full-width RISC-V instructions by trapping to millicode <xentrac>so I think that, if you had a 32-byte instruction cache full of 16-bit-long instructions, you could execute all your inner loops (of 16 instructions or less) at microcode speed <xentrac>the raw SRAM bits for that cache would add 2048 transistors to the CPU (if using 8T SRAM), and the control logic would likely double that, but you'd still have a 32-bit RISC CPU with an ample register file and one-instruction-per-cycle inner loops for less than the size of the ARM 2 <xentrac>probably a major reason the CPUs of the 80s were so shitty is that they were designed without the benefit of decent tooling <aggi>i've not seen any free/open SoC/SBC deployment in practice, which let's say could run some linux2 kernel (or any other which had support for ARM2 hardware), and did NOT rely upon xilinx/altera <aggi>while staying closely aligned to bootstrappable criteria <aggi>i recall European Aerospace (Airbus) who tried to come up with some design and manufacturing for their SPARC Leon and nowadays RISC-V too <aggi>can't nor won't re-confirm their supply-chains, but i recall having seen Altera again, to implement these "free" and "open" designs <aggi>in any case, it's gigantic efforts remaining, to come up with something free/open which remains bootstrappable down to hardware/firmware level <xentrac>yeah, you can't run Linux on SeRV. I think yosys is just barely capable of getting VexRiscV running on Lattice hardware <xentrac>there are lots of people running Linux on soft cores on Xilinx and Altera FPGAs <roconnor>Soon you'll be able to make that in your basement. <xentrac>many people have built model ships that are more complex in their basement <xentrac>I mean a 74HC00 is four gates, a 74HC08 is eight "gates", a 74HC06 or 74HC16 is three "gates", a 74HC595 is 16 "gates", a CD4051 is something like ten, so we're talking about something on the order of 250 chips <xentrac>soldering together 250 parts is not exactly the Manhattan Project <bauen1>xentrac: don't use 74xxx chips, simply get a parallel programmable EEPROM chip, then you can load them with the lookup table for a few more gates at once, or go in the direction of CPLDs <bauen1>xentrac: throw in a few parallel access registers, or rather some parallel SRAM, and you don't need "large" gates for that <bauen1>xentrac: and at that point you might want to look into "serializing" CPU designs, so you can use e.g. 4-bit busses and simply do 32/4 cycles per computation etc..., simply to make it easier on the gates, but more importantly on the wiring <bauen1>but I guess you know most if not all of that ^^ <bauen1>once you have something that can e.g. speak SPI and do sufficiently fast crypto, then you can simply outsource a lot of the "hard" hardware parts of implementing networking hardware and talking to SSDs etc... to something you connect to over SPI (or something better), said hardware can then be fully untrusted and do things like implement a very large singular disk for you <xentrac>bauen1: yeah, EPROMs can be a useful step in the direction of fully programmable logic. You can reasonably do a 4-bit ALU in a 27C64 64K EPROM <xentrac>not sure what the EEPROM equivalent is <bauen1>xentrac: and there's another fun trick you can still from formal verification / SAT solvers, you don't actually need fast trusted hardware for the compilation, you "simply" need trusted hardware that can verify a certain property about your bootstrap chain / compilation, similar to how you can verify the result of a SAT solver very quickly, so you can have "unverified" solvers come up with solutions <xentrac>(is the data that your trusted hardware checks) <xentrac>in particular I'm sort of enamored of the Metamath model with Metamath Zero <xentrac>but my understanding of formal methods is extremely weak, so nobody else should put much weight on that :-) <bauen1>xentrac: something I had thought about a long time ago, was that you could (or maybe even should) design trusted hardware, that has exactly one job: ensure that every bootstrap step can never modify the source code, or the results of the bootstrap step before it <xentrac> https://arxiv.org/abs/1907.01283 “Specifying verified x86 software from scratch” Mario Carneiro wants to prove a #Metamath verifier correct with #Metamath. #foundations-of-mathematics #formal-methods <bauen1>xentrac: because that will allow you to "recover" the bootstrap from a certain point, while maintaing trust, so you don't need to start compiling from zero everytime, especially on very slow trusted hardware, but can restart in the middle, while still being certain that the result is trusted <xentrac>for that kind of thing it seems like strong determinism would be desirable <bauen1>xentrac: re Metamath, it is wild what people come up with <bauen1>xentrac: not necessarily even, you simply need hardware that says "this storage is read-only", "this storage is cleared and read-write during this stage, but after it is read-only" - possibly also with a way to hash each stage <xentrac>so that you know that if you get a non-byte-identical compilation result at any stage, it's because something relevant has changed (gone wrong or been changed intentionally) <bauen1>the strong determinism would come later, since that is probably quite hard to achieve in practice <xentrac>I don't think it's that hard to achieve in practice <xentrac>I mean it's always been routine for compiling new versions of GCC <xentrac>and at this point large fractions of Debian are being successfully built reproducibly <bauen1>Hmm, I guess so, still strong determinism would not be a requirement for this scheme to work <bauen1>But strong determinism would be a very useful property, since then you could combine this "this stage is read-only" with "and here are the input hashes and the output hash" <bauen1>so kind of like live-bootstrap already does iirc, but formalized <bauen1>And you can then use that to show that if you verified the code up to stage X, that you can use the code from stage X to verify stage X+n, since stage X is trusted, and no matter what you do with the later stages, they can not modify your stage X anymore <bauen1>which is then just a formal way of expressing the "audit the code with [trusted] tools" <xentrac>I feel like there are different kinds of "trusted" in play, and it's easy to confuse them and come to false conclusions <xentrac>I should emphasize that 250 parts above is kind of an upper bound. By using parts with a higher level of integration, or programmable logic as bauen1 suggests, many people have built CPUs with many fewer chips