<littlebobeep>oriansj: I don't understand why non-human made source code is considered a "blob" <unmatched-paren>ogg vorbis, opengl, opengles, libpng, librsvg, gmp, dbus, imagemagick, openal, opencl, vlc, lua, libxml, oracle db, tcl, zlib, fuse, libffi, libcurl, libcups, libmagic, libtar, libusb, curses, openssl, pthreads, x11, ... <unmatched-paren>And the most monstrous makefile i have ever seen, generated by a utility called 'fpcmake' (written in pascal) <vagrantc>littlebobeep: i think the question is not weather a non-human made it so much as can a human read it? <stikonas>oriansj: I'm not sure if stage0-posix-x86 would actually simplify things much but we'll see <stikonas>M2-Planet is a compiler, not sure why it says transpiler <littlebobeep>stikonas: What does it mean to call it "M1" assembly isn't assembly standardized for a given ISA? <stikonas>littlebobeep: M1 is just different syntax compared to GAS <oriansj>littlebobeep: do you consider guile's psyntax.pp human readable? <stikonas>littlebobeep: M1 syntax is designed in a way that is easier to parse in assembly <stikonas>cause we actually have to write initial version of M0 in hex2 code <stikonas>so we have e.g. "RD_A7 !214 ADDI" instead of "addi a7, 214" <stikonas>so M0 simply replaces RD_A7 with .80080000, encodes !214 into hex using appropriate risc-v instruction type (I-type if I remember correctly) and ADDI is replaced with 13000000 <stikonas>and then those hex strings are passed into hex2 binary <stikonas>which processes them, does the linking and outputs actual binary <stikonas>on the other hand, "addi a7, 214" is much harder to parse as you would need to keep more state, e.g. assembler needs to know how to encode 214 <stikonas>based on the instruction type that it observed earlier <oriansj>stikonas: well the difference between compile and transpile is compilers convert from a higher level language to a lower lever language and transpiles just convert between two different languages. However as C is just portable assembly and M1 is also portable assembly; it wouldn't really be fair to call it compiling <stikonas>well, then gcc is also transpiler but oh well... <oriansj>but that might just me being too harsh on C <oriansj>and me being wrong again but it is a bit late for a name change <stikonas>anyway, it doesn't matter too much how one calls it <oriansj>well M2-Place (PLAtform CompilEr) would kinda work but not well <oriansj>also you did a much better job on riscv's M1 assembly than the thrown together mess I did for x86 and AMD64 <oriansj>even janneke's M1 output looks much closer to gas but then again, I never expected much programming beyound cc_* to be done in M1 <stikonas>well, it's easier to redo the same work to another arch <stikonas>and we had to rethink some stuff to deal with fixed length arch <oriansj>and the byte to word refactoring made for a much more advanced M1 and hex2 compared to x86's <muurkha>I learned something interesting about RISC-V last night. Olof Kindgren has a working RISC-V design called SERV that can be realized in about 200 4-input LUTs and 250 D flip-flops, which is pretty much the simplest I've ever seen a general-purpose CPU <muurkha>it's equivalent to about 500-1000 gates (and 250 flip-flops) <muurkha>4-input LUTs are the kind in the iCE40UP5K chip on this FPGA devboard I got yesterday <muurkha>I think Xilinx and Altera use 6-input and 5-input LUTs <muurkha>but the README doesn't talk about how small it is quantitatively, I got that from an EEVblog forum thread <muurkha>even my own ridiculously simple Calculus Vaporis design is about 600 NAND gates, and it's a huge pain to program compared to RISC-V (unless you're hand-assembling I guess, in which case the RISC-V instruction format feels like a malicious prank) <muurkha>it might be a good idea to rename M1 to a longer name because after last year most people will think "M1 assembly" is for Apple's M1 chip <oriansj>muurkha: well we don't need to hand-assemble RISC-V anymore now that stage0-posix has a bootstrap for it <oriansj>and Apple can go *FUCK THEMSELVES* with a rusty spoon <oriansj>and the search term is mescc-tools anyway <oriansj>not like stage0 is that good of a search term anyway lol <oriansj>muurkha: I'd argue live-bootstrapping and Gnu Mes are the two big entry names we have <oriansj>and those are where people will probably find what they want anyway <muurkha>[gnu mes] surprisingly finds me only things about GNU Mes <muurkha>but of course [mes] tells me, "El mes es una unidad astronómica de tiempo, usada en el calendario como el período que tarda la Luna en dar una vuelta alrededor de la Tierra." <oriansj>beside dongcarl's talks are probably the most viewed talks about our work because of the crypto community <muurkha>the #1 hit is a Wikipedia disambiguation page that doesn't mention it, the #3 hit is about what holidays happen this month ("mes") <oriansj>which reminds me; thank you very much stikonas and fossy for live-bootstrap. The death threat emails stopped shortly after you got the path from stage0 to TCC working. (probably my biggest anger against the crypto community) <muurkha>why were people threatenig you with death? <muurkha>I also thank you very much but don't have as much reason to <oriansj>because I was holding up their crypto chain's trust from being complete <oriansj>guess they didn't understand WTF they were talking about and just used the breaking bitcoin slides and assumed it was my fault for not closing the gap between stage0 and mes <muurkha>anyway I'm super excited to have this FPGA devboard. for the first time in my life I have the tools I need to design and build a working CPU, even if that's not a particularly smart way to use an FPGA in production <muurkha>the FPGA is big enough to hold about 20 instantiations of SERV <oriansj>muurkha: who cares if it is smart if it makes you happy <muurkha>PicoRV32? yeah, about 8 times, 5 in a more comfortable configuration <muurkha>it might even be a smart way to do research on CPU design, but I'm not sure I'll manage to do that <oriansj>oh no... you'll just toy around and enjoy yourself. You might even be inspired to play zork on it <muurkha>surely someone has implemented the Z-machine on an FPGA without another CPU before <oriansj>well guess we are the generation that might make libre-hardware the standard <oriansj>libre-silicon is a good half step there <oriansj>and after that technology, Cory Doctorow's walkaways becomes viable <mid-kid>How do I get gcc to look for crt1.o in /usr/lib/musl instead of /usr/lib? <mid-kid>Something tells me I need to adapt STANDARD_STARTFILE_PREFIX in a header in the gcc sources but for some reason the live-bootstrap script doesn't need to do that? <mid-kid>I should probably mention that I'm trying to upgrade gcc after a live-bootstrap sysc build. <mid-kid>Quick question but are file sorted before they're "tar"ed into the repo? <mid-kid>I'm getting different tarballs when not building in a tmpfs <mid-kid>yeah it's the file order that messes up the checksum for gawk-3.0.4_0 <stikonas>there aren't that many symlinks in live-bootstrap <mid-kid>no I'm looking at create_tarball_pkg <stikonas>but it's definitely an improvement to what we had before <stikonas>(we only used to checksum binaries and libraries) <mid-kid>coreutils is built fairly late and provides "sort" <mid-kid>so anything before there relies on how the linux kernel happens to sort files in a tmpfs <mid-kid>which might differ from kernel to kernel, but does differ from filesystem to filesystem <mid-kid>Might be able to write a sort implementation in mes or m2 <stikonas>well, you can try to build sort with meslibc in step 13 <stikonas>although there are probably some problems if I didn't build it in step 13 (although thye might be solvable, it's just that I didn't bother back then if there was no immediate need for sort) <mid-kid>iirc the issue with coreutils was that its source archives don't go back in time far enough <stikonas>no, we didn't have any issue with coreutils archives <mid-kid>yeah for some reason I remember gcc was *needed* to build it but looking at this code that appears to not be the case <stikonas>hmm, so first part of coreutils actually builds tsort <mid-kid>Oh! I didn't notice it in after.kaem <stikonas>there are two makefiles (one for meslibc build, the other is for musl build and builds more utilities <mid-kid>I was already wondering how the hell it was running the main makefile <mid-kid>thanks for pointing me to the right dir lol <stikonas>well, all early build scripts are written in kaem scripts, so basically a list of commands... <stikonas>then once we build make, we put main building logic in custom makefiles <stikonas>and then once bash is built, everything is switched to more powerful scripting and helpers.sh library <oriansj>mid-kid: well if we wrote a sort it would go into mescc-tools-extra <Christoph[m]>unmatched-paren: You want to use Pascal to compile Nim, right? Maybe it is less work to "compile" the Nim-Compiler by hand into an already bootstrapped language? That would of course not bootstrap Pascal, but wouldn't it be easier to translate a Nim-Compiler from Pascal to ??? than to rewrite Pascal from scratch? <unmatched-paren>Christoph[m]: you could say the same for FPC; just hand-translate it. But hand-translating sounds very error-prone; there's probably attributes of Nim that would be lost if you translated it to, say, Go (Go doesn't support tagged unions, for example) <unmatched-paren>the Nim project does provide *machine-translated* sources of the Nim compiler to c, but that's just what the Nim compiler does <stikonas>well, any language can theoretically be bootstrapped this way by porting source to another language <stikonas>probably C++ is a good choice to port to <stikonas>even C to simpler C (mes->mes-m2 took a long time) <stikonas>probably writing a small bootstrap compiler from scrath is often easier <unmatched-paren>free pascal has a lot of features, most of which are not formally specified <oriansj>well it ultimately is up to the person doing the work <oriansj>and my recommendation is always to do what *you* (the person doing the work) finds most fun <unmatched-paren>the other two ways are probably too difficult (transpiling by hand and 'archeology') <stikonas>well, dos itself is not a problem, there is freedos <unmatched-paren>Pascal needs to be extended to be useful; Standard Pascal is pretty primitive afaik <oriansj>unmatched-paren: well what seems like fun to do (ignore restrictions for a minute) <unmatched-paren>so fpc has always used turbo pascal extensions (which it implements itself) <oriansj>unmatched-paren: and what programming language is the most fun for you to use? <unmatched-paren>i've wanted to write a compiler for a while, and this seems like a good opportunity to learn <unmatched-paren>oriansj: probably one of the ones that isn't bootstrapped yet, which would be a bit pointless. it would be a good learning experience to do it in C though <oriansj>unmatched-paren: It isn't pointless because we will bootstrap GHC in the future <stikonas>but even if we bootstrap GHC, it's a much longer bootstrap path than C <stikonas>at least if we go through archeological way of bootstrapping GHC <stikonas>well, it's not a blocker, but might be hard to run... <bauen1>writing compilers in a functional language can however be much more pleasant than in C <bauen1>and you'll pribably get to a point where you want to scrap it anyway <oriansj>remember no language is magic. Those easier to bootstrap are closer to the bootstrapping root and those who are harder to bootstrap just show up later in the tree. <oriansj>and I much prefer unmatched-paren to have a fun experience learning to build a pascal compiler in a language they find fun (like GHC) than having pascal show up lower in the bootstrapping chain (as it doesn't appear even required yet) <oriansj>unless you are here because someone is paying you to bootstrap their software as quickly as possible; your goal should to have as an enjoyable experience bootstrapping as possible. <oriansj>be it writing a Kernel in assembly, bootstrapping assembly in Haskell or just learning as much as possible. Have the fun you want and share with others who might find it neat or useful <unmatched-paren>well, i think i'll enjoy it regardless of the language i write it in <unmatche1-paren>so, i think i'll write it in C, with a QBE backend, and later experiment with perhaps an asm or M1 backend ***unmatche1-paren is now known as unmatched-paren
<unmatched-paren>obviously these wouldn't be relevant to bootstrapping, but they'd help me learn how it all works <unmatched-paren>i'm not sure whether QBE supports inline asm yet though, which would be important to make a runtime library (syscalls etc.) <unmatched-paren>for syscalls, i can see an easy solution: add a `syscall` keyword that lets you call arbitrary syscalls <unmatched-paren>oriansj: i'm not really sure i can say on the readme 'APC is a bootstrap compiler' if it is itself written in a non-bootstrappable language <unmatched-paren>and writing a compiler for $lowlevellang in $highlevellang seems like overengineering to me <unmatched-paren>hm, i just noticed that Spry is mentioned on the bootstrapping wiki front page, it's written in nim <stikonas>I think writing compilers and optimizing them might be different skill sets... <stikonas>e.g. M2-Planet does not do any optimizations <unmatched-paren>stikonas: I am aware that optimization is way harder and unnecessary for bootstrapping :) it'd just be a nice skill to have, and a compiler for a simple (?) language like pascal seems like the perfect testbed <unmatched-paren>if i do decide to add them, i'll probably do it in a different branch, to keep the bootstrap APC simple and easy to audit <unmatched-paren>since i'm reading through the Dragon Book, which has bits about optimization, i might as well learn how to do it <oriansj>unmatched-paren: if pascal was a simple language it would be quick to bootstrap. <oriansj>if it has a boatload of hidden complexity, then no I expect it to be harder work <unmatched-paren>oriansj: it seems simple at its core, but of course we need to implement the object-oriented features and modules etc along with it <oriansj>seems and is in reality are two very different things <unmatched-paren>we mustn't forget inline assembly, interfaces, generics, C FFI, operator overloading, exceptions, and the preprocessor, too :P <unmatched-paren>i'll take it incrementally. as you've said before: bootstrapping is long-term :) <stikonas>well, inline assembly is always trivial to implement <unmatched-paren>stikonas: inline asm might be a bit tricky with QBE, i'm not entirely sure; it isn't implemented in cproc yet <stikonas>hmm, not sure about QBE, maybe it's not so simple there <stikonas>in M2-Planet it's implemented like this: M2-Planet just reads the asm statement lines and outputs them unchanged *unmatched-paren having second thoughts about using QBE until it supports these (pretty important) features <stikonas>well, yes, musl uses some inline asm. Actually tcc also had some trouble with musl's inline asm and I had to patch musl <stikonas>different arches have different M1 macros <stikonas>hmm, maybe in the end LLVM will be easiest... <stikonas>it's mostly if/else blocks that deal with arches in M2 <unmatched-paren>or i could just do assembly :) it can't be *too* hard, right? muurkha's ur-scheme emits x64 directly and they said they weren't very experienced with compilers <unmatched-paren>can GAS handle multiple assembly syntaxes in the same file? fpc supports both att and intel syntax <oriansj>well the only point of LLVM and QBE is if you wanted to punt having to deal with the assembly details <oriansj>otherwise just output assembly in a form binutils likes and move on <unmatched-paren>x64 resources that aren't thousand-page reference manuals are hard to find :/ <stikonas>that's because architecture is complicated... <stikonas>even riscv ISA documentation is something like 150 pages long <unmatched-paren>i found a few riscv guides and reference cards, but not many x64 ones