IRC channel logs
2023-02-15.log
back to list of logs
<oriansj>plasma41: not a bad bootstrapping system. <oriansj>Honestly S-100 bus systems were a tragic loss in spirit. And if one made an S-100 system with a 386 and 4GB of RAM; they probably could run live-bootstrap with very few modifications <oriansj>but honestly any hardware we can eliminate firmware we didn't bootstrap would be a huge win (even if it requires me to do a bunch of porting work) <oriansj>and of course my jerk of a brain wakes me up at 3am with a massively overly ambitious idea; knowing I have work in 5 hours and definitely no where close to enough time or energy to work on said idea. Assuming one had a trusted fab able to produce arbitrary chips up to X transistors: design a full system, CPU and firmware capable of running a POSIX kernel. Thanks brain, that sounds like an even bigger problem than the last one that only <oriansj>took 5+ years and about a dozen brilliant and wonderful people (love all of you bootstrappers) <oriansj>heaven knows I need to actively follow more 0x10c style bootstrapping fantasies <oriansj>Well lets look at the basic requirements that I'll need to figure out how to do: Design a CPU and its pinout, along with how to wireup the most minimal system possible which would probably require RAM, ROM, a clock driver and a serial port (do I go insane and design that chip too or just assume an off the shelf design) <oriansj>figure out if I'm going to do Memory mapped I/O, Port mapped I/O or channel I/O (and have to design that architecture too) <oriansj>or do I just punt hard and go make a 32bit unibus design and shove a bunch of complexity into a few chips and punt on those as long as possible <oriansj>as there are a great many hardware choices that make bootstrapping simpler and easier but add a good bit of complexity to the hardware itself <oriansj>supporting multiple instruction sizes; enable things such as 32bit immediates (which allow us to skip having do do immediate skips in our code) but is more complex than just a single instruction size and is it worth it wouldn't even be known until someone just builds up to that point and looks at the transistor count delta <oriansj>or do I reasonably assume that entire path is always doomed to waste infite time as why would anyone care about another hobby CPU architectures. <oriansj>specify a subset of an existing architecture (like 386) omit the bits that are not needed when bootstrapping and just embrace legacy support will always include mess and bad design decisions. <oriansj>or is the fact one can buy a CPU that implements an architecture the real dividing line? <fossy>i think riscv is probably the best we have right now, particularly because of its smaller instruction set & open design <fossy>TBH, its pretty close to what your spec is there <oriansj>well every Microprocessor ever made is pretty close to the minimal spec <oriansj>The only deviation common is not needing an external clock <oriansj>as chips like the J-11 have clock output pin(s) <muurkha>I don't think a Xeon is "pretty close to the minimal spec", but it's certainly still a microprocessor <muurkha>to run a POSIX kernel in a practical way you probably do need an MMU <muurkha>RISC-V's approach to instruction-sized immediates seems pretty reasonable to me <muurkha>the ADDI instruction has a 12-bit immediate, which is sign-extended (like all RISC-V immediates) and covers the most common cases of immediates directly: 0, 1, -1, 4, 8, 10, 255, things like that <muurkha>for a full 32-bit immediate you precede the ADDI with a LUI, load upper immediate, which has a 20-bit immediate which gets loaded into the high bits of the destination register <muurkha>(or AUIPC to get a PC-relative version, allowing you to relocate your code in memory) <muurkha>the SeRV implementation of RISC-V is about 200 4-LUTs, not counting memory (because it implements full RISC-V it has a bit over 1024 bits of registers; RV32E cuts that almost in half) <muurkha>but SeRV is designed to do unpredictable things in the case of illegal instructions, which doesn't seem like it would be ideal for a trustworthy unbootstrapping path <muurkha>an MMU also helps with the trustworthiness question, quite aside from making it practical to implement POSIX fork() <muurkha>because you can be reasonably sure that wild pointers in user code won't corrupt the kernel <oriansj>well I disagree on the reasonableness of RISC-V's immediates (mostly on grounds of encoding complexity); we did already ultimately bootstrap it to the point where it could be used. <muurkha>I'm not sure how much that buys you in terms of trustworthiness when you're running the compiler that outputs the kernel <muurkha>but it surely cuts down debugging time at least <muurkha>yeah, the encoding of RISC-V's immediates is a pain <oriansj>muurkha: well also doing a builder-hex0 in RISC-V is going to be a nightmare due to those immediates <oriansj>in M0/M1 it isn't so bad but in hex0; eek <muurkha>what if you have a fixed instruction length wider than the address bus? <muurkha>24-bit or 28-bit addresses, say, and 32-bit instructions <muurkha>then you could have a real load-immediate instruction with no hanky-panky <oriansj>why not 32bit addresses and 64bit instructions? <oriansj>it'll be wasteful of memory but now you have a boatload of bits for trivial decoding <muurkha>yeah, the only reason not to do that is that it's wasteful of memory I think <muurkha>you might remember Nguyen and Kay's Chifir has 128-bit instructions <muurkha>32 bits of opcode, 32 bits of destination address, and 32 bits of each source address <muurkha>unfortunately I think this relies on self-modifying code for array indexing <oriansj>well a clean bootstrap architecture doesn't need to be bad <oriansj>heck RISC-V with a few tweaks to encoding and reduced to 16 registers would work <muurkha>Chifir has no general-purpose registers, just memory <oriansj>then AUIPC and LUI can just use 16 bit immediates <oriansj>so you could save an encoding and skip their "compressed instruction <oriansj>" garbage that wastes the majority of the instruction encoding space <muurkha>hmm, I guess you have to steal a couple of bits from the opcode fields to get ADDI up to 16 bits <oriansj>don't you mean add a few as [8bit opcode] [4bit register] [4bit register][16bit register] <oriansj>we would be expanding the opcode to 8 bits <oriansj>(and remove the need for funct3 xop) as there are not that many immediate instructions in RISC-V <muurkha>I was counting the funct3 field as one of the opcode fields <muurkha>even though it's not the field called "opcode", it does encode which operation to perform :) <oriansj>fair enough, in which place we would be stealing exactly 1 bit <muurkha>two, I think, since funct3 is 3 bits and the field called "opcode" is 7 <muurkha>the resulting instruction format would be very readable in hex <oriansj>muurkha: we get to steal 1 bit from each of the registers <muurkha>so to get from 12 to 16 bits of immediate, we reduce opcode bits from 10 bits to 8, reduce rd from 5 bits to 4, reduce rs1 from 5 bits to 4, and reorder the fields to be in a readable order <oriansj>and we can even flip the bit order so that it becomes opcode register immediate register <muurkha>that would dealign the immediate field with byte boundaries, which might be a more important ergonomic consideration <oriansj>well we only have to do 40 instruction opcodes for RV32E <oriansj>muurkha: well byte aligned immediates could enable simpler hex2 <muurkha>also it might make it easier to read hex dumps <oriansj>toss in another 8 instructions to support the M extension and 4 more for S extension and that would do it right? <muurkha>I think M is probably not that important for compilers. I mean you can just call a multiplication or division subroutine <oriansj>Standard Extension for Supervisor-level Instructions <oriansj>which (correct me if I am wrong) should be for MMU support <muurkha>I think it interacts with it but I think the MMU support is not itself given a letter <muurkha>I think the supervisor-level instructions are for things like reading and writing special registers <muurkha>some of which you use for setting up the page tables <muurkha>the page tables specified in the supervisor-level instruction set look very easy to use <oriansj>well then ideally those will map nicely as well <stikonas>janneke: I've replied to your emails, it seems we still have no stage0-posix to mes path on 64 bits <stikonas>(so we don't need to worry about new amd64 defines yet) <stikonas>and perhaps once we start working on it, we can just target new amd64 defines <stikonas>anyway, I've suggested a quick fix that we'll definitely need for 64-bit <janneke>x86_64 is still "nice to have", as i386 works fine for a 64bit bootstrap <stikonas>you should replace #define M2_PTR_SIZE 4 with #define M2_PTR_SIZE (sizeof(void*)) <stikonas>we are likely to hit multiple bugs in 2037 <stikonas>I once tried setting date in qemu beyond that and we have multiple issues <janneke>stikonas: yeah, i think we do that now on the wip-x86_64 branch <stikonas>oh yes, you already fixed it a few days ago <stikonas>I was getting lost in different branches <janneke>ACTION wonders how to deop automagically <stikonas>should be the same set just in different order <janneke>in other news, the guix bootstrap fails with mes-0.24.2; binutils-2.20.1a's "ar" segfaults <stikonas>is binutils 2.20 still using mes libc rather than glibc? <janneke>mes-0.24.2 should fix a longstanding stat64 bug that apparently surfaces when using btrfs <janneke>ACTION tries some bisecting, hoping it's not the stat64 patch that breaks things <janneke>another possibility is rebuiling mes lib c when building the second tcc-boot <stikonas>fossy: potentially we could try upgrading binutils 2.14 to 2.20.1 in live-bootstrap too, but binutils 2.20.1 uses autoconf 2.64, so it would have to go just before GCC <stikonas>we have quite a few packages between binutils and gcc but it's mostly various versions of autotools <stikonas>which presumably will build just find without as <efraim>it might also be on tmpfs, that's where I do my guix building <janneke>and that breaks the bootstrap where? <efraim>same spot, with as where everyone else fails <janneke>i've seen two reports, bash-mesboot0 (which has been removed) and glibc-2.2.5? <janneke>meanwhile, i got gcc-core-mesboot0 built with mes-0.24 + the stat64 patch <janneke>it requires a rebuild of the Mes C Library in tcc-boot <janneke>possibly we're going to get mes-0.24.2 in after all... <vagrantc>janneke: for the most part, mes 0.24.2 is still pretty much x86_64, x86 and armv7 ? <vagrantc>looking at updating in debian ... although even if it theoretically supports somehing else, i probably should no add it at this point <janneke>vagrantc: yes, it's really a bug-fix release <vagrantc>janneke: yeah, it looked like some simple bugfixes, so i thin is appropriate for debian even during this mid-freeze-cycle <janneke>the most important thing fixed is the `stat64' and friends problem on 32bits <vagrantc>that sounds worth fixing ... and would probably be uglier as patches against 0.24.1 <janneke>it seems that when building on tmpfs or btrfs, problems arise using the old `stat' kernel interface <vagrantc>i often use tmpfs ... though i do not think i have tested on an actual x86 or armhf system ... usually an x86 chroot on an x86_64 system, or an arm chroot on an aarch64 system <janneke>the problem only seems to arise in the guix bootstrap <janneke>and tcc-boot0, gzip-mesboot, gnu-make-mesboot0, tcc-boot, patch-mesboot <vagrantc>but i should be able to get 0.24.2 into the upcoming debian release, fwiw <janneke>but then, gcc-core-mesboot0 fails to build