<siraben>wrt. markdown headers I prefer to #+ style since I never really member which one of - or = correspond to which level <siraben>wrt pacing, i'd rather see a project make steady progress over a longer period of time than burn out within a month, especially since we all have work/school/family etc. to attend to <OriansJ>senzilla: for the sake of simplicity just think Architecture that can be implemented in TTL logic and isn't covered by patents nor copyright. That I plan on implementing in bare metal as the final piece of eliminating all possible sources of a trusting trust attack. <OriansJ>janneke: I like to think of mes-m2 as a slow ramp of disolving the outstanding issues in guix's bootstrap tree. For as we make it more powerful; more and more of the pieces that currently depend upon guile will run on it; until finally everything does and guile is finally bootstrapped. <OriansJ>lfam: I think I finally figured out the procedure and boy is it ugly. <xentrac>OriansJ: you keep using the word "TTL", but I don't think that word means what you think it means :) <xentrac>I think you might intend to say "discrete logic", but that isn't what "TTL" means <xentrac>in particular, although TTL is slightly more limited in some ways than more modern families of discrete logic, none of them are really relevant to the assurability or difficulty of a CPU <xentrac>if you build a CPU out of discrete 74HC00 family CMOS gates or (assuming you can somehow source them) discrete 74LS00 family TTL gates, everything about your circuit design and debugging process will be almost exactly identical <xentrac>you can do a wired-AND with 74LS00 gates (but that wastes a lot of power), CMOS has tri-state buffers and TTL doesn't (but you can use open-collector buffers or inverters for almost the same effect), CMOS has a larger noise margin from a voltage perspective, TTL has lower input impedance on the gates and therefore a larger noise marging from a current perspective <xentrac>CMOS can do analog bidirectional multiplexers but that sort of isn't logic; their functions can be replaced with a bus driven open-collector if you somehow have the misfortune of having to use TTL in 2020 <xentrac>but literally anything you can implement in TTL logic you can implement in CMOS logic and vice versa, usually with chip-for-chip replacements, occasionally with changes to some details <xentrac>the big difference is that (a) the CMOS chips are a lot faster, (b) you can get them, (c) they use a hundred times less power <xentrac>building an entire computer in TTL, which is indeed a thing people did in the 1970s, is likely to require you to run a dedicated circuit to power it in your house <xentrac>maybe not! I mean the Datapoint 2200 was technically a computer, and that was only a few hundred watts. but I don't think it could ever run a compiler <xentrac>the reason I keep bringing this up is that when you say "can be implemented in TTL logic" it sounds like you're trying to nail down a really unfortunate implementation choice that isn't useful to promote your actual goals as I understand them <xentrac>since those goals don't include rewiring your house or specifying components that are becoming quite rare, but are easily replaceable by more modern components that are easily available and work better <OriansJ>perhaps I should restrict myself to expressing it terms of implementation with individual discrete gates <xentrac>it's maybe sort of like saying "I want my GUI to run on a 27" CRT monitor". I mean, sure, it should *work* on a 27" CRT if someone has one, but do you really want to buy a 27" CRT in order to build he GUI? <xentrac>yeah, I figured that was probably what you actually meant <OriansJ>xentrac: well I am still working on being a more effective communicator <xentrac>there *is* the question of whether maybe some modern CMOS discrete logic gates are implemented in a smaller process that would be hard to decap and audit with a microscope <xentrac>but I think that they probably aren't because moving them to a smaller process would be lots of risk for little reward <OriansJ>xentrac: the end goal is impossible levels of effort required to compromise the bootstrap <OriansJ>So if they can compromise *EVERY* single hardware platform including those arbitrarily made by kids. <OriansJ>And *EVERY* single port of mescc-tools-seed *IDENTICALLY* <OriansJ>including those written by random college kids <OriansJ>Then well fuck, I have no hope of stopping them. <OriansJ>but aside from that level of effort. I think we will be fine <OriansJ>If someone finds a solution to stopping that level of effort; let me know. Because I can only imagine a paper clip optimizer that might be able to achieve that level of compromise. (The AI that deleted a decade) <siraben>i'm certain that when finished this will be amazing, because it's certainly possible to have an impossibly small bootstrap to modern software but it's been lost over the decades <xentrac>it sounds like we've maybe just hit a major important milestone <xentrac>357 bytes to GCC on (some variant of) amd64? <xentrac>the pieces are finally coming together after an enormous amount of effort by several people <3 <siraben>xentrac: oh what's the milestone? is it really done? <xentrac>I haven't tried it myself, but it sounded like yes: <xentrac>20:49 < fossy> so we actually do have a full path from 357 bytes to gcc, abliet a mildly complex one <xentrac>20:49 < janneke> but most of the credit goes to OriansJ and his marvellous m2-planet <xentrac>20:57 < mihi> janneke, fossy: As far as I know the current guix "boostrap" cheats by using some shell and/or guile for orchestrating the <xentrac> bootstrap. So technically, there is probably still some "plumbing" missing to get a full bootstrap that only uses kaem and <xentrac>20:58 < fossy> mihi: the ideal goal for x86 would be from efi as you hashed out the other day <xentrac>20:59 < fossy> but what I am trying to accomplish using live-bootstrap is basically that, the stage0, kaem and kernel seeds <siraben>ok so the cheating part is the part to resolve <senzilla>OriansJ: Thanks for the explanation of Knight. I don't understand much from the PDF included in stage0, but guess you're aiming for simplicity with this architecture? Or is there another reason you couldn't go with RISC-V that's fully open source? <senzilla>fossy: I'm curious about the path through EFI that you referred to earlier. Is part of the plan having a compiler that eventually run in an EFI environment as part of bootstrapping a more complete POSIX-like environment? <fossy>senzilla: yes a stage0 monitor in efi <xentrac>senzilla: it's possible submarine patents will surface on RISC-V, as they have with H.264; that is less likely for a 40-year-old architecture. the lawsuit would not take long to win <xentrac>and Knight has the advantage of having evidently been successfully implemented in discrete logic, in practice <xentrac>while that might turn out to be substantially more difficult with RISC-V, since that wasn't really one of its design objectives <xentrac>my personal opinion is that Knight is about 10x more complicated than something like the PDP-8/X or Wirth RISC, but theoretically better things that nobody's implemented a stage0 bootstrap for are not better in practice <OriansJ>xentrac: also there is nothing stopping someone from porting a stage0 bootstrap to Wirth RISC or PDP-8/X except the desire to do so. <OriansJ>senzilla: ultimately I want the list of supported architectures to grow to infinity but I have limited amounts of time and am forced to choose which pieces I can allocate time to. <senzilla>I think the EDK2 UEFI environment has a Lua interpreter. Might be interesting to explore to write a C compiler in Lua, if one does not wanna write a C compiler in C using the EDK2 stdlibc <OriansJ>you break a stream of chars into tokens and then pattern match the tokens to generate the output assembly <OriansJ>toss in generating a list of types if you want to support structs too <senzilla>Yeah, I've never really looked into writing a compiler before. But I suppose the challenge is getting it to compile something real and useful, and not just trivial example code. Like a compiler in EFI that can compile the Linux kernel and a POSIX shell or something. <senzilla>It's probably easier to aim towards compiling BSD components, eg the OpenBSD kernel and their implementation of the Korn Shell, as they're a lot smaller and simpler, generally speaking <OriansJ>senzilla: well useful in C is a pretty low bar once one supports structs and inline assembly <OriansJ>unless you think being able to bootstrap a Haskell compiler isn't a useful thing to do. <siraben>OriansJ: I just ran a build of the original blynn-compiler again, noticed that it printed out timing information, should we have a script that also does this? <siraben>would be useful information to see if changes are improving/hurting performance <OriansJ>siraben: well time -v would work when wrapping the steps <OriansJ>but that would require the time binary to be installed in people's paths <siraben>OriansJ: if you segfaulted gdb, time to use gdb to debug gdb! ***ChanServ sets mode: +o rekado
***wowaname is now known as opal
<OriansJ>senzilla: everything is easy that you know how to do. I've done my best to make the low level steps of the bootstrap only exercise hard and absolutely not math hard. <senzilla>OriansJ: I definitely appreciate all the hard work by you and everyone else here :) <OriansJ>senzilla: it is a boatload of fun for me and we try to ensure everyone only does the work they enjoy if possible as the goals are a tad aggressive. <senzilla>Being able to bootstrap a computer from something you can trust or easily inspect is such a fundamentally important thing <senzilla>All other computing problems become trivial in comparison when you take a step back and think about bootstrapping :) <OriansJ>well; all major computer problems at their core are usually social rather than technical. <senzilla>I've been toying a bit with the comments around EFI earlier... I think I might give it a try to port PCC (Portable C Compiler) to run in the EDK2 EFI shell.