<oriansj>stikonas: well mes-m2 really should work with GCC as well; as there is nothing in M2-Planet that isn't also supported by GCC. It is just a matter of figuring out the gap. <stikonas>yes, although it's probably a low priority task <stikonas>I guess having it build with M2-Mesoplanet would be more important <oriansj>stikonas: a bit below getting Mes-M2 using M2libc ***genr8eofl__ is now known as genr8eofl
<fossy>cannot figure out why exactly tagging is support <stikonas[m]>the autogenerated tarball would not have files needed to build flex from source. Being able to build without autogenerated files is exactly the reason why we picked that version... But I guess I can see that tagging new tarball would add a bit of workload to flex maintainer <oriansj>fossy: what if I offered to pay them for the support of tagging a commit for a new tarball? <stikonas>we can probably survive with the old tarball. Or if necessary we can fork a repo and make a release ourselves <oriansj>stikonas: it is a question of worth. if it costs $10 and saves us 2 hours of headaches, it would be worth it to me. <oriansj>if it costs $10K but only saves a few minutes, not worth it to me <stikonas>well, old tarball is working now. If it disappears from that ftp server, maybe then we can think... <stikonas>(we do have a few local copies, so even if it disappears we'll not lose it) <oriansj>stikonas: let us nip it in the bud and address it before it becomes a bigger problem *pabs3 suggests to web.archive.org/save it at minimum <nimaje>yes, but do you have something where you want to use brainfuck in bootstrapping? <bauen1>siraben: an interpreter written in your average assembly language is also quite easy to do <bauen1>siraben: however brainfuck i/o is rather limited in practice, and you probably don't want to write anything > 1024 characters by hand, it's a nighmare, i tried, managed to write a simple echo irc bot before i managed to convince myself that it's a very very bad idea <muurkha>I feel like the main problems with brainfuck for bootstrapping are factoring and performance transparency <muurkha>I mean there are others but those are the worst ones <muurkha>it lacks performance transparency because you don't have operations like add, xor, or compare for equality; you have to synthesize them out of more primitive operations like increment <muurkha>an optimizing BF implementation may be able to recognize your synthetic add and use a native add, but it's hard to predict when <muurkha>as for factoring, well, you don't have subroutines and I haven't figured out a way to get data pointers either <muurkha>the great thing about brainfuck is that you can write an interpreter for it in half an hour on any reasonable platform. (maybe oriansj can do it in five minutes, but it took me half an hour) <muurkha>it would be nice to have something that is within an order of magnitude in complexity of implementation but that doesn't share brainfuck's flaws <muurkha>then we could use it to write CPU simulators and things like a bootstrapping kernel <bauen1>i'd argue that rv32g is probably a decent candidate, it's a very clean isa that is designed to be easy to implement in hardware, granted writing assembly for it is a bit annoying <bauen1>but i have yet to take a closer look into the privileged rv32g specifications <muurkha>privileged rv32g is definitely not within an order of magnitude of half an hour of implementation effort <muurkha>even unprivileged rv32i probably isn't <bauen1>muurkha: unprivileged rv32i most certainly isn't, it's a few days tops if you have some light background in vhdl and cpu design <bauen1>muurkha: but it's arguably something that you can eventually run linux on, so you won't have to "throw away" your effort at some point in the bootstrap (you might need a faster cpu however) <muurkha>how does vhdl help you write a software simulator? <bauen1>muurkha: writing a software simulator should be even easier <muurkha>that's true! and you don't have to write your own compiler <muurkha>yes, but I predict it would still take me longer than 5 hours <bauen1>muurkha: the rv32i alu is incredibly simple <muurkha>it is, but the complexity of a software simulator never comes from the alu <bauen1>muurkha: you really don't have that many components, you have the alu, a few very simple branch instructions, a register file, some load and store instructions (which are very easy to implement if you're not doing hardware) and some immediate decoding <bauen1>granted i haven't tried to implement anything but rv32i <muurkha>yeah, and the funky hardware-optimized bit orders, and calculating branch destinations, plus whatever I/O you need to get started <bauen1>and by all means it's much easier than designing your own ISA, because you're gonna make some terrible decisions in that part alone if it's your first time ... <muurkha>but even M and C are pretty simple to implement, and for a uniprocessor software sim A is basically a no-op <bauen1>muurkha: the immediate decoder is very simple to implement, there's basically 6 different ways to do it, i.e. 6 C one liner functions, and then you just have to use the right function depending on what opcode you're looking at <bauen1>muurkha: i implemented an rv32i vhdl cpu, and it only took me 4 days, 2 of which where debugging memory timings, so i'm very positive you can do a lot better when writing a software simulator <bauen1>this reminds me that i still want to polish that thing a bit and see if i can get it running on an fpga <muurkha>I'm not saying risc-v is bad compared to other CPUs; i love it! I'm just saying that, say, the immediate decoder is roughly the same implementation complexity as all of brainfuck <bauen1>muurkha: maybe a bit complexer than brainfuck without loops, but not as complex as brainfuck with loops, they're very easy to get wrong, for the immediate decoder you just follow the 2 tables in the manual <muurkha>the RISC-V privileged spec is also not that bad. it's a real breath of fresh air after the nightmare bullshit that is basically any other MMU <muurkha>have you gotten your design running in an FPGA yet? <bauen1>muurkha: no, exams kind of dereailed that plan a bit <muurkha>I thought that might be why you were debugging memory timings <muurkha>for me the great thing about RISC-V (especially RV32G) is how boring it is <muurkha>"no actually this doesn't have to be clever and confusing" <muurkha>the exception being the funky bit order <stikonas>siraben: brainfuck implementation in C might be simple, but one would have to write it in .hex0 or something similar, basically machine code. This part is doable. But the question is what's next? Presumably you wouldn't want to go back to assembly, so you would have to write a compiler or interpreter for a proper language <stikonas>and I wouldn't want to write a C compiler in brainfuck <bauen1>and every bigger brainfuck program i know of wasn't written in brainfuck, it was compiled to brainfuck in some way or another <siraben>yeah, so it's a poor choice of bootstrapping language unfortunately <stikonas>in principle if somebody could write a small interpreter that is more readable than brainfuck it might be useful <stikonas>but so far nobody wrote anything like that <stikonas>then we could go to arch-independent code much earlier than M2-Planet <stikonas>but it's probably hard to write an interpreter that is smaller than M0