IRC channel logs

2023-05-13.log

back to list of logs

<stikonas>yes, but we don't need to implement C17 directly
<stikonas>C is reasonably stable, so once you have C99 compiler, it's fairly easy to build something that supports C17
<muurkha>even GNU89 gets you pretty far
<muurkha>more notes about uxn and bootstrapping: https://100r.co/site/weathering_software_winter.html
<muurkha>"I wanted a way of doing computers that nobody could take away from me."
<muurkha>it covers the NES, Smalltalk, Oberon, Pascal, Plan9, Java, Inferno, the Commodore 64, Kolmogorov complexity, Chifir, Subleq OISC, and so on
<drakonis>ah, nice.
<Irvise_>The oldest copy I found from GNAT is GNAT 3.07 which was designed to work with GCC 2.7.2, and it is still not bootstrappable...
<Irvise_>There is another issue here. Each GNAT release requires a specific GCC version and a specific previous GNAT version. That means, that if we were going to reproduce the original "path" (assuming it could be done directly without bootstrapping issues), then that would require the compilation of dozens of GCC/GNAT pairs...
<Irvise_>That is a bit issue.
<Irvise_>oriansj: I would say that the Ada-Ed approach towards bootstrapping Ada is toast :/
<Irvise_>s/bit/big
<Irvise_>And just for the curious, GNAT 3.07 is from 1996.
<Irvise_>I would say that creating a compiler that can target the same GCC version as the one in the bootstrap path for C would be ideal. It would just be a single step.
<Irvise_>We would need the bootstrapping of three tools: gnat, gnatbind and gnatlink.
<oriansj>Irvise_: well that is far from ideal.
<oriansj>but I guess people working on Ada never had a problem on putting all the work on the compiler writer's shoulders
<oriansj>muurkha: yeah, a fuly natural response given that experience.
<Irvise_>Not really, it is actually worse. Before Ada was mainlined in GCC 3.1, it required a specific GCC version because it maintained a bunch of patches for each version. So one would have to patch old GCC, compile Ada somehow; rinse and repeat... Imagine bootstrapping this in ARM/RISC-V...
<Irvise_>An external compiler seems way easier somehow xD
<oriansj>Irvise_: when you put it that way, even using Haskell to bootstrap Ada wouldn't even be a step back
<oriansj>(assuming one used the subset of Haskell that we did already bootstrap)
<Irvise_>Yup. But we were already looking into TR7 Scheme (or Lotus) as they can be compiled for x86*, ARM and RISC-V with TCC support and are written in simple C :)
<Irvise_>We want to get before the GCC compilation :)
<muurkha>Irvise_: yeah, I think the GNAT path was bootstrapped using proprietary Ada compilers
<muurkha>it might be more reasonable to create a compiler that can compile current GNAT
<muurkha>because I suspect current GNAT can compile the previous versions
<Christoph[m]>Oh, there's a subset of Haskell already bootstrapped? How does that work?
<stikonas[m]>Christoph: well, there is hugs and nh99 I think
<stikonas[m]>(Or maybe 98)
<oriansj>stikonas[m]: indeed and the blynn haskell compiler can be bootstrapped by M2-Planet
<oriansj>so if one uses a subset of haskell, they are effectively bootstrapped already; we just don't have a working step from that subset of haskell to GHC yet
<oriansj>which might mean haskell might be an easier bootstrap than Ada
<oriansj>There was a proposal to write a lisp interpreter in the blynn Haskell subset, which could run MesCC; so that the root languages would be Haskell, C and Lisp
<oriansj>but it would be certainly cool to see someone making something cool in that Haskell subset
<stikonas[m]>Well, building mes with M2-Planet is simpler
<stikonas[m]>Especially given that M2-Planet compatibility wasn't upstreamed to blynn
<oriansj>very true;
<stikonas_>hmm, mescc riscv64 define work is going quite slowly, though mostly because I'm not too familiar with scheme
<oriansj>stikonas: well porting mescc always took longer than M2-planet and RISC-V wasn't a fast port either.
<ericson2314>emilytrau: it looks like kaem-minimal is unused?
<ericson2314>were you perhaps trying to break up stage0-posix-x86.nix?
<stikonas[m]>ericson2314: I think breaking up stage0-posix-x86 was the reason why kaem-minimal was not used
<stikonas[m]>in particular kaem-minimal does not support environmental variables
<ericson2314>ah OK
<ericson2314>makes sense
<ericson2314>it would also be good to use derivationStrict