IRC channel logs
2022-12-07.log
back to list of logs
<stikonas>do we not want to add size of the object to address when we calculate a[1]? <stikonas>we should just use offset expression * 24 <stikonas>rather than expression << log2(8) (on 64-bit arches) <stikonas>was it an optimization from when the type size was only power of 2... <oriansj>stikonas: I believe that is for an array of objects; we do the cheap thing and allocate a 2^n size block for each index; so that we can index it cheaply by just doing a bitshift of the index (no muliplication) <stikonas>ok, so we can't do this optimization for structs <stikonas>which is a blocker for getting struct a[i].member working <stikonas>in particular I need to define struct ** type <stikonas>and fix backlinks, so that current_target->type works for structs <drakonis>hm, zig no longer has any c++ in its bootstrap path <stikonas>though for bootstrapping, I think c++ should be fine, we can bootstrap g++ <oriansj>well c++ was never hard to bootstrap once we got gcc <oriansj>but lets just hope zig doesn't do any hops which break its bootstrap chain <qyliss>The C is generated though, right? <qyliss>I was trying to understand this earlier. Not sure I got it right, but it looked to me like they were replacing human-written C++ with machine-generated C or a WASI binary. <qyliss>Yeah, where does the WASI binary come from? <drakonis>the new stage 1 source is in zig's repository <qyliss>How do you know those sources correspond to the binary? <oriansj>so zig; now requires a convoluted path to bootstrap... *shakes head* <qyliss>Like, how do you verify zig1.wasm.zst corresponds to its source, when you don't already have a zig compiler? <oriansj>qyliss: probably bootstrapping an earlier zig compiler <qyliss>oriansj: They claim there's no need for multiple compiler versions, but they don't seem to have taken this into account. <oriansj>qyliss: they never take proper bootstrapping into account *ever* <qyliss>I thought zig was one of the good ones. <oriansj>a literal 637 KB binary file; seriously? <stikonas>well, commit message says replace this commit with something else but still strage, why commit binary blobs in the first place <qyliss>(and it's merged, including the binary) <oriansj>talk about downgrading from "reasonable to bootstrap" to "we be fucked" <stikonas>The idea here is to use a small WASI binary as a stage1 kernel that is committed to source control and therefore can be used to build any commit from source <oriansj>the question isn't what purpose the binary has; so much as can it be bootstrapped bit for bit <stikonas>oh, but generated C is not any more human inspectable... <qyliss>which would still not be real bootstrapping <stikonas>so basically you need to build older zig <stikonas>and then you can bootstrap 1.0 iteratively through intermediate stages <qyliss>drakonis: is the *plan* a work in progress? <drakonis>no, the bootstrapping process, i suppose <qyliss>because at the end of the plan outlined in that issue zig still won't be O(1) bootstrappable <oriansj>and zig needs someone to keep an eye to keeping its bootstrap path alive <oriansj>even if it means an ugly guix build chain <stikonas>which is not the end of the world but a bit annoying <drakonis>eh, just the first 50 are relevant to the discussion <drakonis>hewing and hawing about zig not properly bootstrapping helps nobody <drakonis>i was going to say participating on improving the process but its never so simple, is it? <qyliss>maybe they'll get a better answer <qyliss>but there's no point anybody else joining in and bridaging them with the same question <qyliss>overall it's just frustrating to see a project that seemed to understand the importance of bootstrappability miss the mark like this <qyliss>more so than if it was just some new language that didn't care at all <qyliss>because it suggests a lack of understanding of why bootstrappability is important (trust, auditability) <drakonis>i'm listening to the recording right now <drakonis>seems like the binary blob will go away in the future <drakonis>but only when there's a replacement for it <drakonis>after there's a spec and someone uses that spec to write a bootstrapping compiler for zig <drakonis>its far easier to write a bootstrapping compiler for zig than rust <qyliss>otoh, a bootstrapping compiler exists for Rust already! <qyliss>(mrustc, unless you mean something different by a bootstrapping compiler) <qyliss>I don't know if it can compile rustc yet <stikonas[m]>It's not just rustc that needs building, you also need cargo <qyliss>mrustc takes care of that though, doesn't it? <qyliss>but in principle you could use minicargo+gccrs, right? <oriansj>perhaps the C++ version can be (or is??) feature parity with the blob; which if true one could delete the blob and verify that it is our mzig approach going forward. <stikonas>oriansj: my impression was that they want to do some breaking changes and not keep updating C++ version <oriansj>if they are going to do breaking changes against the binary, I have run out of all possible reasons for them to even have that blob <stikonas>so if zig maintainers don't want to maintain it, somebody else would have to <stikonas>oriansj: I thought they'll be updating binary <stikonas>until they decided to stabilize for 1.0 release <drakonis>watch the first 15 minutes to get the gist of the whole thing or the first 50 minutes to get the full view <drakonis>as the rest of the recording is andrew working on the implementation <oriansj>drakonis: and mzig is a pun on mrustc; which was just me suggesting we take the C++ version that was hand written and ensure it is able to be feature parity with the binary and thus give us a path forward. <oriansj>But if they are going to replace the binary, then we might not have enough free developers to make that a viable option. <oriansj>(I will be watching the stream ideally later tonight [waiting on it to finish downloading]) <stikonas>in that case just do O(n) bootstrap rather than O(1)... <oriansj>stikonas: assuming we don't hit another gap like we did with Bison <stikonas>(I didn't have time to watch stream, though I might be able to soon prepare a PR to add struct[index].member support to M2-Planet <oriansj>stikonas: now that is more exciting to me <stikonas>it will be less optimal than shifts (push, multiply and pop) <stikonas>but I guess it's more correct when you have non-power-of-two structs <oriansj>which honestly is probably for the best <stikonas>I've added doubly indirect struct types (since those are used in e.g. M1) <stikonas>I don't think we need to support anything higher... <oriansj>we have more than enough to bootstrap a haskell like language; so probably <stikonas>it's not hard to add, but I doubt we will need tripple indirection in bootstrapping <stikonas>anyway, I've got x86 and amd64 working (and amd64 version is good enough to remove that UEFI hack <stikonas>though I'm slightly unhappy with the fact that it will be the third place with e.g. emit_out("mul_rbx\n") <stikonas>but I don't know if it's worth factoring it out into a separate function... <stikonas>well, it's just a small snippet unlike loading and storing stuff...