<vagrantc>didn't get anything useful out of it beyond that, going to try again without the bootstrap build and hopefully it'll still fail the same way... <vagrantc>and this time pass arguments so i can inspect the reulting failure... <oriansj>tfgbvhrdjeugbfrrkbhtuibleehcvgvuctfrbvltlnld <achaninja>oriansj: I thought if we had a gas compatible subset assembler and simple static elf linker written in some variant of the assembly C compilers - its possible to get a fast but less than perfect bootstrap <vagrantc>hrm. i build it again and i don't get the test suite to fail. yay. i guess. <vagrantc>so as of mes 0.24, the supported architectures are basicall x86, x86_64 and arm still? <stikonas>mes itself is fairly easy to port, there are working patches, but mescc is much harder <vagrantc>looks like there's mention of it in the code, at least <vagrantc>it definitely didn't build ... configure requires passing --with-courage, and then fails <vagrantc>also tried cross-building arm from x86_64 ... but that failed ... maybe there's no way to disable the tests <vagrantc>build-aux/build-scaffold.sh: line 71: ./exit-42: cannot execute binary file: Exec format error <oriansj>tfgbvhrdjeughclkbculuidtnhrvkjhveieuhlduffbu <muurkha>I figured it was either that or that it was your distress code <oriansj>I must say using i3 with a 2 year old is a dangerous combo <oriansj>only 3 key presses needed to get to a shell <oriansj>achaninja: nothing is a step backwards IF useful infromation is learned and *SHARED* <achaninja>I'm currently going through the tcc bootstrap steps manually <achaninja>I had some trouble tracking down the exact git commit used by livebootstrap <achaninja>I would appreciate getting to the bottom of that <nckx>The g stands for git (commits are purely hex). <muurkha>oh yeah, g isn't a hex digit, is it? <nckx>muurkha: Hush. It's the secret hex digit. <achaninja>that commit is totally detached from history it seems <nckx>It's not detached, it's the mes-0.23 branch, but yeh, maybe. <Hagfish>it's so great someone is looking at this process with fresh eyes, thank you! <nckx>(Using a foo-x.y branch instead of a tag is a bit unusual, no argument.) <Hagfish>untagged releases definitely seems like something that could be improved, but there might be some good reason for it <Hagfish>at first i thought the filename might be a hash of the contents <achaninja>I guess git fsck can be uesd to check the hash <Hagfish>maybe tcc 0.9.26 is only a temporary solution and once it is removed this whole issue will be moot <Hagfish>i think it's historically been hard to push upstream tcc in a good direction, which is why bootstrapping basically requires maintaining a fork of tcc <Hagfish>i'm not sure what can be done to simplify that fork <oriansj>Hagfish: Well mescc is growing and developing as a C compiler so it is only a matter of time before janneke gets mescc to the level we don't need a fork of tcc and maybe be able to use even the latest tcc release <achaninja>imposing your will on others isn't a good look <achaninja>especially when it involves making their code uglier to serve your purposes <achaninja>with more help I'm sure we can get mescc to build everything <achaninja>tcc development is fairly stale, it would be nice if we could support a bunch of bootstrap c compilers <achaninja>but yeah - I guess im not adding much by repeating that <Hagfish>oriansj: yeah, that's a great way to route around that mess :) <Hagfish>achaninja: i agree about not imposing your will on others, but that goes both ways <Hagfish>it's not good if the tcc maintainers are gatekeeping their project with a narrow vision, to the detriment of the real users of the project <Hagfish>but i don't know what difficult tradeoffs they're having to make, so i won't criticise them <muurkha>maybe it is good because the narrow vision is more important than the real users <muurkha>but in any case it's free software, they can't stop the users from forking it <Hagfish>what if it's the wrong vision, though? <muurkha>we'll find out when the last stars go out <Hagfish>i'm wondering if there is a critical mass of tcc contributors who might prefer to join a "tbc" (tiny bootstrapping compiler) project <achaninja>thats what forks are, you can't tell someone else their vision is wrong haha <Hagfish>that's quite a big hurdle involved in forking a community (which is a good and bad thing) <Hagfish>it means you don't end up with millions of unsustainable confusing forks, but it can harm the community <achaninja>I really don't think bootstrapping requires a community <muurkha>git clone, git remote add ..., git push -u gitlab master <Hagfish>but you need to pick a new name, and clarify your new vision, and encourage people to contribute to it <achaninja>btw random idea - anyone thought about the possible uses of web assembly in bootstrapping? <Hagfish>architectural decisions have to be made about what goes in and what is rejected, and it can take time for that dust to settle <muurkha>no you don't, you can just push it to gitlab <muurkha>and if you like the results you can tell people about them <muurkha>you can call it "Hagfish's tcc fork" until you come up with a better name <muurkha>encouraging people to contribute to it is not a good idea until your new vision is clear <muurkha>but you can merge in changes from their forks <Hagfish>yeah, maybe that's the biggest hurdle: actually delivering something that's better than what came before <achaninja>well the problem was you weren't really advancing tcc - you were actively regressing it <Hagfish>hmm, yeah, removing features would be unkind <Hagfish>or even just making the code harder to read <achaninja>its no surprise people would be hostile to that idea <muurkha>I mean TCC is licensed under GPL so unless they remove arm-gen.c you can merge in their changes if you like them <achaninja>'im just gonna delete your hard written code or wrap it in #ifdef soup' <muurkha>(most of TCC is relicensed under the X11 license) <Hagfish>yeah, there are probably ways of supporting all goals in one codebase, but at the cost of readability (which in practice means auditability) <achaninja>i think the obvious way and correct want is just improve mescc <Hagfish>achaninja: as for webasm, i haven't though about how that might fit in <achaninja>so just help or donate to whoever is doing that lol <achaninja>i guess it doesn't help that much - i suppose it would serve the purpose that mes currently serves <muurkha>wasm isn't platform-neutral any more than Linux is <muurkha>I mean it runs on lots of platforms but that doesn't mean you have less platforms, it means you have one more <achaninja>muurkha: if you had a wasi implementation in m2 it absolutely would be <achaninja>but i guess its not as useful as mes thinking more <muurkha>implementing a bootstrapping virtual machine might be a useful thing to do but it probably shouldn't be wasm. it could reasonably be a small subset of wasm and then you could run its executables ("modules") on a regular wasm implementation <muurkha>the other night I think we were talking about bf and a slightly extended version of it called "sf", who was that? <muurkha>something like Chifir might have a better cost/benefit ratio though <achaninja>haha i dunno if using bf helps readability at all <achaninja>the point is for each layer to be more readable than the last too <muurkha>yeah, I don't think bf is very readable <achaninja>otherwise we could just compiled gcc with -S <muurkha>another VM similar to Chifir which has been implemented by more people is the UM of the Cult of the Bound Variable <muurkha>it's maybe a little more practical, though maybe less readable <dnm>Possibly my favorite ICFP contest <muurkha>there's another RISC that's also probably wirth mentioning <dnm>Wirth's RISC5? (as distinct from RISC-V) Or another? <dnm>I should pay more attention to this channel. Here's me trying to do that. :) <muurkha>I don't think any of Chifir, UM, or Wirth-the-RISC are adequate for *archival* (Chifir's purpose) but for *bootstrapping* they should all be fine <muurkha>none of the three are as unreadable as BF, I think, but they still all require uncomfortably circuitous forms of programming *dnm makes a note to go read the Chifir paper from VPRI <dnm>I have some initial reactions to your Bootstrapping instruction set page, but I feel I should check those and maybe test them first before I toss largely unformed thoughts and feelings out there. <dnm>And part of that means I should read the paper. ;) <muurkha>oh, I'd be interested to hear your unformed thoughts too ;) <dnm>Nah, I wouldn't; they wouldn't stand up to any inspection or pressure. <dnm>At a minimum, I need to understand the original goal Chifir's nominally shooting for. <muurkha>it might be worth mentioning that Olof Kindgren wrote a RISC-V implementation in a bit over 200 4-LUTs, which is about the same size as Calculus Vaporis: https://github.com/olofk/serv <dnm>I might disagree with you on preferences for register-based machines, video with SIMD, *no* undefined behavior, etc. <dnm>But I don't necessarily have good, articulable, well-thought out reasons for those yet. <muurkha>Chifir's goal is to make a physical artifact which, if discovered by a programmer-archaeologist a few centuries in the future when computer architectures are quite different, will enable her to get Smalltalk-76 running on whatever computer hardware she's using in a fun afternoon hack <muurkha>Chifir doesn't have registers in the sense of accumulators, it's entirely a memory-to-memory design <muurkha>on Chifir code density suffers and you need self-modifying code for indexed memory access <dnm>As an aside: one could argue about the real difference for this sort of purpose between the parts of RISC-V you'd actually implement and DLX, but if we bucket those as more or less the same thing, we could compare them to other approaches. <dnm>See, no one remembers the "classics" (I say partially in jest). ;P <oriansj>well as someone with a good bit of bootstrapping in assembly experience, I must say an architecture with 4 registers+sp+pc is good enough to do some rather complex things simply <dnm>Yep. I mean inasmuch as RISC-V is basically MIPS, and DLX is a simplified MIPS... ;) <oriansj>the max instruction is just an optimization that isn't needed in bootstrapping <muurkha>dnm: RISC-V's I-type instructions have a 12-bit immediate instead of 16-bit <dnm>Actually, y'know what? <oriansj>int32 and int8 memory operations are good enough (no need for int16 or uint16) <muurkha>agreed, oriansj, that's what RISC-V does <muurkha>RISC-V also has an instruction encoding that seems deliberately perverse at first glance in the interest of reducing fanout to speed up minimal-hardware-complexity implementations <dnm>This is a *terrible* idea, but I was already kinda leaning somewhat this way anyway: I should repurpose at least one of Precursors I have(n't yet sold to shapr) towards a sort of bootstrap thing with their RISC-V implementation (at least to start), without using Xous and Rust and all that... <dnm>Although that's maybe a bit afield from the VM conversation really. <oriansj>dnm: the real question is would it be fun <muurkha>dnm: for the same reason RISC-V has an S-type instruction for stores instead of the I-type used for loads <muurkha>that way the destination register, if any, is always in the same place in the instruction *dnm goes to look up the Unwhatever datasheet/spec again to remind what the debug connectors already populated are... <muurkha>I think synthesizing some RISC-V open core into the Precursor's FPGA is a fantastic idea <dnm>oriansj: True, and always a tricky one to answer <oriansj>dnm: and very heavily based on the people involved <dnm>muurkha: Well they already have one. But yeah, I was thinking about that too, separately. But if you just wanted to start with RISC-V as your thing and work on the VM bit, you could just use theirs to start. <dnm>I'm just thinking about RISC-V HW I already have without firing up ISE, Quartus, or Vivado. It's the SiFive stuff and the Precursors. <oriansj>muurkha: well we do have risc-v (32+64) bootstrapped. it just becomes a question of getting a minimal RISC-V hardware implementation and getting it able to run the stage0 riscv work <muurkha>dnm: yeah. and Jessica Clarke pointed out that if you're just using RISC-V as a software-implemented virtual machine, you don't need to shuffle the bitfields the way RISC-V does <dnm>Unmatched, that's what it's called. I never remember. <muurkha>SiFive board names are hard to remember <dnm>Yeah. I have plenty of RISC-V gripes of varying degrees. <muurkha>IIRC there's at least one RISC-V core that synthesizes fine with yosys/nextpnr and can run on an icestick <oriansj>dnm: everyone who looks closely at RISC-V have issues with it <dnm>Everyone who looks closely at any ISA has issues with it. <dnm>Tale as old as time. <oriansj>dnm: well yes. to love something means to see its flaws and to feel safe enough to speak openly about them. <muurkha>heh, it's nice to see you mellowing on RISC-V :) <oriansj>muurkha: well stikonas really saved me a great deal of pain and now it isn't so bad to work with <dnm>I *think* this will work, but need to do more digging & reading. <dnm>OK, anyway, that was kind of a tangent. <muurkha>dnm: reading the Symbolics 3600 instruction set papers the other week I was thinking it might be interesting to try something in that direction on a modern FPGA <dnm>Ah, a dream I've occasionally returned to over the last ~20 years or so. <dnm>I'm sure it's eminently doable really, Just a lot of work. <dnm>Though I was thinking more Ivory class machines, but same diff. <muurkha>have you found ISA-level docs on them? <dnm>i.e., just implement the Ivory VLM in RTL <muurkha>might be less work with something like Migen or Bluespec than it would be in Verilog <dnm>Doubt that would be the hard part regardless. <dnm>oriansj: Totally agreed. <dnm>(Well, maybe not *totally*, but yeah, I get the sentiment) <dnm>Hah, Kragen beat me to it. <oriansj>muurkha: minor bug fixes too if we want to start undermining the perspective <oriansj>those are super important to making real progress *dnm idly wonders how to get some nominal amount of funding to do some of this stuff, probably thinking that way just because he just remembered to file state business tax filings ("no revenue") earlier today. <dnm>Not that funding is at all required. <muurkha>yesterday I was chatting with a guy who was using a thing called PVS for some parser synthesis <dnm>But would make it nice. <muurkha>working on this project I've been working on <dnm>Or the static source code analyzer? <muurkha>coincidentally PVS is mentioned in the DLX page on WP so I followed the link <oriansj>dnm: you might want to talk to janneke as he did get funding for this work <dnm>muurkha: I dug all that up years ago <dnm>The work in germany at that uni <dnm>On the DLX clone/variant <dnm>Glad you found it and had that reaction! <muurkha>guy named Shankar, nice guy, doing good work <dnm>Assuming that's what you're gonna say <dnm>I could be totally wrong <muurkha>on the Wikipedia page for PVS it cites a paper on PVS from 01992 <dnm>Oh, maybe I jumped the gun <muurkha>mouseover: "Natarajan Shankar is a computer scientist working at SRI International in Menlo Park, California, where he leads the Symbolic Analysis Laboratory." <dnm>I'm surprised he hasn't decamped to Kestrel <muurkha>hope I didn't say anything too arrogant <dnm>Well, not really; I don't know him at all. <muurkha>why, what's compelling about Kestrel? <dnm>I only have unduly snarky answers. I should say the folks I've interacted with there seem to be doing interesting work, and doing it well. <dnm>But the undue snark begins with "block" and ends with "chain". <dnm>Kestrel *is* more of an ACL2 shop, also. <muurkha>I'm glad I accepted his correction about when Schorre published META-II, I'd said 1968 or something, and he said it was actually the early 60s <dnm>muurkha: So if you're interested, I did find the work that was published at one point as a book on a verified essentially DLX core, where that work was done in PVS of the era. I can unearth it out of my Downloads folder from a few years ago and post it somewhere. <dnm>I had grandiose ideas/thoughts/dreams a few years back of trying to move the industry in a particular way with essentially a derivative thing of it. <dnm>Back when I arguably gave more of a crap. <muurkha>well, Waterman and Krstić did exactly that <dnm>I wish I and others were successful internally in open sourcing some of the ACL2-related work we did on some ISA verification activity, but alas. <dnm>Neither here nor there. <muurkha>he also corrected me about the termination properties of PEG parsing <muurkha>because it's undecidable whether a PEG nonterminal can match the empty string, it's also undecidable whether a PEG is secretly left-recursive, which means it's undecidable whether it can loop infinitely <muurkha>I suspect that even if Shankar thought he could convert Kestrel to PVS (or that he'd be willing to invest his time in ACL2 instead), he'd have to take a demotion if he left SRI <dnm>Doesn't everyone want those sweet sweet crypto consulting dollars? <muurkha>he's been an SRI Fellow for 13 years <muurkha>he's basically a tenured department chair at one of the most prestigious research institutions in the world <oriansj>dnm: my grant total of crypto contributations has been $10 from nixo and a series of death threats <dnm>Kestrel's been an SRI spin off since '81, so what? 41 years? I know none of this matters. <oriansj>as reward for *checks watch* 6 years of hard work and community building <oriansj>but outside of money, I have had lots of fun and got to spend time with lots of amazing people (of whom I would gladly call friend) <achaninja>I saw the NLnet funding, that is cool, you demonstrated everything works and <achaninja>it seems some things sort of need the final tweaks <oriansj>achaninja: well bootstrapping is a marathon and there is no done to reach <oriansj>there will always be new and exciting things to do and achieve and build and share <achaninja>i guess it can always be made faster and shorter <oriansj>achaninja: it can be made to suit *YOU* <oriansj>If someone wants to pick up doing scheme in assembly to run Mescc, they can do it <oriansj>if someone wants to do a kernel in FORTH, go forth and create wonders <achaninja>I am most interested in improving mescc atm - though my scheme is pretty bad its gonna take a while before i can help <oriansj>if you just wanna play and learn; we encourage that too <achaninja>i don't really see a reason why mescc can't compile bitfields or 64 bit or anything else other than getting the funding/manpower <dnm>Link to whatever mescc is? <dnm>Sorry, I'm coming in cold. <oriansj>that can build its own interpreter written in C <oriansj>which enabled us to bridge the gap from hex to GCC+Guile <achaninja>a short and reliable path from assembly to scheme exists <achaninja>the path from scheme to a fully functional C compiler works, but is a bit fiddly <oriansj>dnm: have you seen my talk notes yet? <oriansj>it is a little behind on details but the brush strokes are there <achaninja>which aims to be a C compiler, linker, assembler and libc <achaninja>so i have quite a few experiments to run haha <oriansj>achaninja: good because the more there are, the more places a trusting trust attack would have to deal with <oriansj>cross-platform reproducible diverse n way compilation with m way seed possiblity space <oriansj>I wonder if a formal proof of Trusting Trust impossibility can be created by us just making the problem space that much fun <achaninja>yeah, actually I'm not sure but maybe it is possible to prove it <achaninja>or at least define the assumptions that make it impossible <stikonas[m]>achaninja: scc is in principle interesting but how are you going to build it? <stikonas[m]>the problem is that we don't really have make this early, so one would have to write some kaem script <stikonas[m]>mes also has a bit of this, but it's build script is much shorter and it was possible to write by hand. tcc is actually simpler in this regard because it's only 1 file to compile <stikonas>I guess building scc after make would probably be easy <stikonas>fossy: I'm thinking about cleaning sysc /usr a bit. So instead of transfering the whole /usr from sysa, we can just reinstall only a subset of .tar.bz2 packages from sysa <stikonas>which would be manually specified as we don't need to transfer everything, i.e. stuff like tcc and some old versions of other software can be dropped <stikonas>achaninja: though if we build scc after make, it might still be immediately useful it we can use it to build heirloom-tools <achaninja>stikonas i would like to build things with mescc <achaninja>Make it unnessary, I can write my own build scripts <achaninja>scc is not yet ready though, the linker is just a stup <achaninja>for my uses, (forgive the typing, I'm on a bad keyboard) <achaninja>nothing against tcc, I just think an alternative would be cool <stikonas>oh, no linker yet. So do people use some other linker in the meantime? Or is it just not possible to do anything yet <achaninja>its not more capable then tcc atm - it depends largely on what you are compiling and if you have an assembler/linker via other means <achaninja>I'm still working on some things to deal with that haha <stikonas>yeah, then you might need to wait for more capable linker. Very early bootstrap uses hex2 as a linker, so it's completely incompatible with other compilers not designed for hex2. Later tcc itself is used until binutils when we switch to its linker <achaninja>I might be able to implement the things I need <fossy>stikonas: yeah, that sounds reasonable to me <fossy>i would like to just install tar/bash and reinstall the packages in sysc rather than transfer /usr, that would be nice <stikonas>actually also gzip because we don't have any package for it <stikonas>I have some early code but having some issue <stikonas>somehow autoconf does not work (or to be more precise autom4te-2.61) <fossy>m4 does point ot /usr/bin/m4 <fossy>'t know where else it could... <stikonas>/usr/src/bash-5.1/build/bash-5.1 # command -v m4 <stikonas>though why does it only happen when installing from packages <fossy>because pre-package i made it transfer sbin over to bin at sysc <fossy>so it still did that after package <fossy>i guess we should just make usr/sbin symlink to usr/bin from as soon as we can <stikonas>ok, I'll make a symlink as part of my changes <stikonas>I'm installing coreutils first then sed then rest is in any order <stikonas>so I can make symlink after coreutils is done <stikonas>fossy: I also noticed something strange with automake, so I created an issue <stikonas>it's actually installed to /usr/bin, so that's fine, not sure why command -v picked up sbin <oriansj>m4 really doesn't belong in /usr/sbin <stikonas>it's just that `command -v` got confused by /usr/sbin -> /usr/bin symlink <oriansj>I get symlinks from /bin ->/usr/bin and /sbin -> /usr/sbin but i don't get why link /usr/sbin -> /usr/bin <stikonas>anyway, it's not the symlink that is breaking autom4te, something else <oriansj>bin and sbin are supposed to be kept separate for security and administration reasons <stikonas>well, it's somewhat less of an issue in tightly controlled environment <stikonas>but yeah, I don't think we need that symlink <oriansj>or even the sbin folder until you need to start making filesystems <stikonas>fossy: while looking at packages, I've also noticed that bzip2 package is broken <stikonas>let me open an issue, so that we don't forget <stikonas>hmm, something bad is happening when perl calls system command <stikonas>somehow pipes/redirections there are broken <muurkha>aha! and in particular spw20.langsec.org/papers/parsley-langsec2020.pdf is the paper that describes the work Shankar was describing on Thursday (though two years ago) ***bandali_ is now known as bandali