IRC channel logs
2023-10-20.log
back to list of logs
<oriansj>stikonas: well it will increase the upper bound for argv from 1MB to 2MB; although I believe the reason selected for 256 entries was to align with a POSIX standard <oriansj>but other than that I have no object to the increase if it is actually useful to you ^_^ <muurkha>rekado: I agree that preventing ocean acidification is a huge deal, and that stratospheric aerosols won't help with that <muurkha>it turns out that with serpentinization of olivine the energy requirement for sequestration is amazingly modest; the hard part is getting it out of the atmosphere <oriansj>as an engineering, just solve that problem with infinite energy; no but in hey we can't get people to turn down their thermostat to prevent people from dying social problem. Yeah, quite difficult <stikonas>oriansj: it's probably the minimum in POSIX... bash certainly supports more <stikonas>oriansj: the use case is to catm all meslibc files <stikonas>we could catm over intermediate temp files if you we want to keep 256 though... <stikonas>though I'm not sure how builder-hex0 behaves with more... <stikonas>oh, maybe let me first sync some small change to comments of riscv bootstrap seeds <stikonas>this just changes M1 macros to lowercase <stikonas>we already had that in stage-posix-riscv* <stikonas>(for riscv we use identical defines in M2libc and meslibc) <matrix_bridge><emilytrau> stikonas: thanks for that kaem change, it is helpful. i currently hack around it with 2 calls to catm <matrix_bridge><Andrius Štikonas> emilytrau: yeah, that's what I was doing too <matrix_bridge><Andrius Štikonas> emilytrau: by the way, did you have problems with tcc and weak symbols? <oriansj>emilytrau: well mescc-tools and mescc-tools-extra exist to make other bootstrapper lives easier. So any changes you think will make things better/easier are usually a pretty easy merge/request <stikonas>on x86 I was hitting this when building musl <stikonas>but on riscv this was already an issue when rebuilding bootstrappable tinycc <matrix_bridge><emilytrau> i was definitely hitting that issue. that's so easy <stikonas>I've created a bug in live-bootstrap to switch to this patch <oriansj>bootstraps only get better with love ^_^ <stikonas>if somebody wants a go at it feel free, I also tagged it with "good first issue" <matrix_bridge><emilytrau> we also sped up mescc builds a ton by parallelising each source file compilation into its own derivation using this list <matrix_bridge><Andrius Štikonas> Well, live-bootstrap can't do that, it needs to be able to run without threads in early bootstrap <oriansj>but it has the advantage of no race conditions <muurkha>oriansj: well, we don't have infinite energy, but we do have three orders of magnitude more available from solar than we've ever used of fossil fuels, and solar is now cheaper too <muurkha>plenty of energy for atmospheric carbon capture <oriansj>muurkha: true, not to mention a boatload of nuclear and all the energy we could capture if we make a dyson ring. <muurkha>those have the problem of being more expensive than fossil fuels rather than cheaper, at least at the moment <oriansj>much cheaper if one does account for the full costs of the fuel wastes and associated costs usually shifted into the extranalities column. <muurkha>plausibly not cheaper even then, depending on how expensive atmospheric carbon capture turns out to be <muurkha>eventually the price of a Dyson spherewill surely be cheaper <nektro>how's the mes wip-x86_64 branch going? <nektro>i saw 0.24.2 was still the latest version <stikonas>nektro: but bootstrap of tinycc is only partial <stikonas>it can actually build tcc-mes binary but that binary segfaults right now <stikonas>that number 0xf0245cdd gets sign extended to 64-bits and becomes negative <nektro>yeah thats super exciting, will love to try it once i get some riscv hardware <stikonas>on visionfive2 mes takes maybe a week till you get to tcc <nektro>oh wow, yeah thats slower than i thought u were gonna say <stikonas>after mes and before mes is not too bad I guess <nektro>but that can always be improved, still an impressive accomplishment <nektro>and the chips will get way faster tooo <stikonas>well, once you get to gcc it's not too slow <stikonas>e.g. can build binutils in 30 minutes or so <janneke>nektro: i'm sure you're aware that x86_64 can be bootstrapped perfectly fine using x86 initially <janneke>(which is also why we have been postponing x86_64 when we hit difficulties) <janneke>emilytrau: are you also splitting-up the bootstrappable-tcc build? <matrix_bridge><emilytrau> not at the moment but i can see how it's done in the bootstrap scripts. might have a whack at parsllelising that 😁 <janneke>emilytrau: yeah it could speed-up building bootstrappable-tcc by an order of magnitude <janneke>(well, it's an ugly hack of course, but so much better than wasting time) <janneke>someone would need to find a way to translate that into guix :) <pabs3>has some discussion of open hardware that requires proprietary software to edit the source or build etc <[exa]>this would kinda imply that you need a fab with fully oss firmware and everything, right? <muurkha>a lot of OSHW is stuff like PCB layouts and 3-D printing designs, not semiconductor masks <muurkha>but fundamentally yeah as long as you can't 3-D print your semiconductor fab you aren't going to get the benefits of open source in hardware <muurkha>that's what we thought about computer vision 15 years ago before ImageNet came out <oriansj>[exa]: well yes, kinda but if people are willing to put in the work. We definitely give people the option to build their own everything but most likely fabbing stuff will continue to be a social activity as cooperation and specialization will continue to be essential. <oriansj>as if you print a plastic CPU, you'll likely be limited to 100Mhz but those with the ability to do silicon lithography could hit the 4+Ghz mark <oriansj>although the number of transistors per spot is a bit tight <muurkha>oriansj: you can't fit even an 8-bit CPU in one of their tiles; they hold about 256-512 gates. and the chip doesn't have enough pins for 64-bit memory <oriansj>and I thought it was more like 1K gates per tile <muurkha>I think doing some kind of design would be very worthwhile, you can definitely do a CPU in 1000 gates <oriansj>well an 8bit PC does really put a hard limit on the assembler you can run but hex0 can definitely run in 256bytes code+data <oriansj>and the 15 8bit registers; well use those bits to make 7 16bit registers or 3 32bit registers and it would be more than enough for a good stack architecture <oriansj>The fixed 8 pins for the dip switch inputs and the 8 fixed pins for LED output and only 10 pins for general I/O. So 4 pins for SPI and 6 pins for expansion... <oriansj>It would have been so much nicer if they gave us all 26 pins of I/O to something we could plug into a breadboard and we could do the rest from there. <notgull>the open hardware bootstrap chain begin? What would the seed be? Do we start at logic gates, or do we just assume that those are compromised and try to go deeper? <oriansj>notgull: we start with the work that seems the most fun to work on <oriansj>so if using premade gates and fpgas seems like fun to you, go for it <oriansj>if you want to make those gates and fpgas from individual transistors, more power to you <notgull>Okay then, I guess I'll start by smelting my own iron <oriansj>if you want to build those transistors, diodes and resistors from sand, sweet. love to read about it <oriansj>notgull: love to see your notes and progress ^_^ <oriansj>the ultimate goal is full and complete understanding from nothing to modern Guix/ Linux distro of your choice <oriansj>(or *BSD or haiku or any other free as in freedom software distribution out there) <oriansj>who does the work, decides what work is to be done and how. <oriansj>on the topic of bootstrapping Iron and other metals <oriansj>They are in emacs org-mode for ease of reference (feel free to git clone if you find it interesting) <oriansj>as all of the designs are on the same chip, in theory one could plug multiple copies of the same cards with different dip settings and have all of the functionality of a complete computer. <muurkha>oriansj: that's great, do those all fit into a single tile? <muurkha>the PDP-8 was one of the things I thought that would take about 1000 gates <muurkha>notgull: btw are you serious about the iron? <muurkha>RV32E is convenient enough to run a wide range of software, but the 32× slowdown (presumably due to being bit-serial?) in nanoV is probably tempting to optimize away <[exa]>oriansj: 100Mhz plastic CPUs can be printed now??? <oriansj>[exa]: that is the current theoretical upper bound but a 4Mhz z80 has been plastic printed previously <[exa]>does it have some other name that can be googled or so? ("plastic printed chips" gives me poker results :D ) <[exa]>I honestly never heard about doing tis so quite curious <[exa]>ACTION a happy sharp mz800 owner <[exa]>I need to read up on these things <muurkha>electronics has a huge speed advantage at any given scale <muurkha>conceivably if you're limited by energy rather than by scale, the balance tips the other way, like Drexler's rod logic <muurkha>relatedly 19:05 < hprmbridge> nmz787> libresilicon docs seem pretty decent <muurkha>and runs at 8MHz at one instruction per cycle IIRC <muurkha>a 4MHz Z80 is more like 5 cycles per instruction, so it's an order of magnitude slower. which still is fast enough for some applications, of course <muurkha>but when you're talking about printing your processor on plastic, if you aren't concerned about hardware backdoors!, this is kind of the market you're competing in <muurkha>it's hard to imagine what kind of product can tolerate a big sheet of plastic (and a battery!) but not a SOT23 <oriansj>muurkha: yeah modern micro-asics are crazy powerful and dirt cheap.