IRC channel logs
2024-01-31.log
back to list of logs
<fossy>most of the prs ive pushed still need fixing lol so don't merge any yet <stikonas>though you can always mark them as drafts <stikonas>I'm still surprised that build systems need users though <stikonas>I mean I understand that for normal system I would like to have users <stikonas>but these days lots of people build stuff in the containeer as namespaced root <stikonas>anywya, generally looks like nice improvements <fossy>stikonas: not sure if build systems is really the right word tbh, i was referring to package manager build systems <fossy>and adjacent things such as gentoo prefix <stikonas>yeah, that is still strange but oh well... <stikonas>I would think that prefix should only care about stuff inside that prefix... <fossy>yeah agreed it doesn't make complete semse to me <oriansj>muurkha: I have been reading your Pennoncel architecture note; if you switch to 16 registers, then you can reduce down to 2 instruction formats and only need to support a 16bit immediate. <muurkha>oriansj: hmm, that's an interesting idea; 16 registers is certainly still quite tolerable, but I think you'd *need* to support only a 16-bit immediate with only two instruction formats <muurkha>but, if you only support a 16-bit immediate, you can only directly call subroutines within a 64K range (or 256K if you shift), which seems like a big limitation? if you have a scratch register you could call into the larger range with li16; movt; jalr which I guess might be okay <muurkha>you lose the byte-alignment of fields, but maybe nibble-alignment is just as good <muurkha>I'm assuming the two formats are BBW (opcode8 srcreg4 dstreg4 imm16) and BRRR (opcode8 srcreg8 srcreg8 dstreg8) <janneke>if you install guix and run `guix build hello --no-substitutes', the full source bootstrap will be built before your eyes <Googulator>janneke: does that actually rebuild everything, not just "hello" itself? <Googulator>I definitely remember using guix build with "--no-substitutes", but it didn't look like a full rebuild starting from seeds <Googulator>exact command was `guix build cl-yale-haskell --no-substitutes` <Googulator>I did that when I was debugging yale-haskell on clisp <Googulator>it rebuilt clisp itself, plus cl-yale-haskell (which failed), but nothing more <Googulator>anyway, bootstrappable.org doesn't even link to the Guix full source bootstrap, only to the earlier reduced binary seed one <matrix_bridge><Andrius Štikonas> Googulator: I think you need to guix gc everything first <matrix_bridge><Andrius Štikonas> Otherwise it would use previously downloaded substitutes <matrix_bridge><Andrius Štikonas> --no-substitutes only applies for new stuff <matrix_bridge><Andrius Štikonas> And bootstrapple.org does not link to any new stuff like kernel bootstrap either <fossy>stikonas: what's the right way to use your gentoo-bootstrap overlay for rust? <fossy>do you emerge -1 each subsequent version? <stikonas>openjdk bootstrap is a bit more user friendly in that regard <fossy>didn't think there'd be a better way <stikonas>fossy: so have you managed to get there from live-bootstrap? <sam_>stikonas: (I do want to fix that, btw, or at least guide someone else to fix it) <sam_>i have a rough plan for what needs to be done <sam_>i just need to find someone to do it <fossy>stikonas: unfortunately not yet <stikonas>fossy: oh, you might also need GCC 12 or less <stikonas>but I'm too lazy (or too busy) to backport them <stikonas>especially given that there might be new mrustc release soonish that will target rust 1.74 <fossy>sam_: while you're around, live-bootstrap is now able to create a gentoo prefix. I was trying to make a seed stage3 for catalyst by doing ROOT=rootfs emerge -e @system, but that still installs everything to EPREFIX, (eg, my EPREFIX was /gentoo, and it was installing everything into rootfs/gentoo, whereas i just want things to go straight into rootfs/) <sam_>stikonas: the gist is, we already have the _downside_ of slotting right now because rust-bin and rust are coinstallable (as ebuilds cannot pick the right one to use, virtual/rust might be satisfied, but rustc might not be the version depended on), so we may as well do it properly, we just need to add some small infra in an eclass to let ebuilds properly pick a version <sam_>then we can slot dev-lang/rust itself trivially <sam_>fossy: yeah, that's also then ROOT= I think; we need to improve our bootstrapping story for ROOT and it's on my mind but I don't yet have a plan <sam_>fossy: also thank you for the update! <stikonas>fossy: still, if you got emerge working, then you are mostly there <stikonas>I'm unfortunately much slower trying to debug tcc... <fossy>yeah, just trying to see if i can toggle some flags/variables here and there to "deprefix" the prefix emerge <fossy>might try installing portage to / instead <oriansj>muurkha: 32KB is more than plenty for 99% of functions; just put the jump target that is greater than 64KB out at the end of the function (or if you are in a function that is greater than 32KB in size, you can do a jump load combo like we have in M2-Planet <oriansj>and for BBW I would do: opcode8 dstreg4 srcreg4 imm16 and for BRRR I would do opcode8 dstreg4 srcreg4 srcreg4 xop4 xop8 (that way you can set xop4 to zero and keep byte and nybble alignment and later when you need extra opcodes, you can just set xop4 to 0001) <oriansj>and the 64KB address space of 16bits maps nicely to a 64KB L1 cache <oriansj>or if you love bit shifting (like the original ARM design did) you can use the xop4 as the shift value <oriansj>(but that seems a bit of a waste to me) <oriansj>Googulator: yeah we have a huge documentation problem (as that is what our website and wiki effectively are) <oriansj>we need someone interested in just writing about what is going on and updating those various pieces to reflect the work that has been done and is in progress. <Googulator>oriansj: it probably doesn't help the documentation situation that the website is coded in Scheme <Googulator>the functional-declarative style of Scheme is a good fit for markup (HTML is also declarative), but Lisp syntax is still intimidating to non-Lispers <oriansj>we don't even need proper markup, just raw text and simple wrapping <oriansj>basic support for images and not much else <oriansj>heck it should work on gopher or gemini as the information is what matters <Googulator>oriansj: I also don't see any means to contribute to the website, e.g. no pull request functionality <Googulator>I guess one could send patches to the bootstrappable mailing list