IRC channel logs

<oriansj>ekaitz: I look forward to seeing your talk ^_^ it looked interesting but life got in the way of watching the live stream -_-

<oriansj>deesix: well it is definitely a step in the right direction; although it is incorrect on the 3rd slide as one can buy 32bit processors with 3KB of RAM and 16KB of Flash for $0.04/per (Which is enough to run hex2 or M0)

<oriansj>perhaps that is the slowest and most memory constrained self-hosting computer that they have yet achieved?

<oriansj>(listening to the talk and it looks like that was what they really mean)

<fossy>364M gcc-10.4.0_0.tar.bz2

<fossy>o.o

<fossy>thats 10x the size of the previous gcc

<fossy>now to test in qemu then should be 99% done

<fossy>a bit of that size is cause of a new binary lto-dump but i don't see any way to disable it.. or if its required..

<fossy>idk much about lto

<fossy>didn't explicitly enable it

<fossy>and cc1{,plus} are just massive now (260MB each)

<fossy>and it is statically linked so that contributes

<stikonas[m]>LTO is likely to be configure option

<stikonas[m]>fossy: and large part of it might be debug symbols

<stikonas[m]>We don't strip them

<stikonas[m]>We possibly could try but when I tried to run strip on python, resulting python binary was just segfaulting

<efraim>I was there at the Self-Hosting FPGA talk at FOSDEM, very interesting talk

<stikonas[m]>Yes, deesix linked it here earlier

<stikonas[m]>efraim: rust in guix potentially uses prebuilt binaries

<efraim>stikonas[m]: send a bug so I don't forget about it

<stikonas[m]>Yeah, I can do that one I'm back in the evening

<efraim>thanks

<efraim>I wonder how far back it goes. and if we have any windows static libraries also.

<stikonas[m]>It seemed to only have amd64 elf binaries

<stikonas[m]>Probably simple rm would fix them

<stikonas[m]>Anyway, I'll report it to guix bugtracker in the evening

<efraim>thanks

<muurkha>a simple rm would fix most people

<oriansj>muurkha: I believe that would actually be more correctly classified as a "work around" for a problem that can't be solved rationally.

<Christoph[m]>oriansj: Did you see the discussion on prescheme in https://logs.guix.gnu.org/spritely/2023-02-07.log#162254 ? I wanted to ask you:

<Christoph[m]>1. You once planned a bootstrap scheme, maybe is prescheme a sufficient solution?

<Christoph[m]>2. The discussion there is also about if perhaps prescheme can be compiled with a simple C compiler. There's plenty of knowledge about simple C compilers in this room, maybe someone can help?

<muurkha>heh

<muurkha>Christoph[m]: you mean, like, an S-expression syntax front end to a simple compiler that with a different syntactic frontend compiles C?

<muurkha>most of a simple C compiler is the syntactic frontend though

<Christoph[m]>Hm, in the other channel, they said that prescheme compiles to C. Maybe the simpler C compiler is needed to compile that result.

<stikonas>but you still need to comple the prescheme to C compiler

<stikonas>ok, I think it's this one https://github.com/nineties-retro/sps

<stikonas>so it's written in pre-scheme itself

<oriansj>Christoph[m]: no I did not but thank you for the link ^_^

<oriansj>the bootstrap scheme I am playing with is supposed to be self-hosting and as easy (or ideally easier) to implement in assembly than cc_* (otherwise there is no point and just do mes.c in assembly)

<oriansj>and usually when people talk about simpler C compilers, they usually refer to TCC (which is by no definition a simple program)

<oriansj>and when we looked more seriously at prescheme in the past we found janneke's Mes.c superior in many ways and ultimately not worth the effort to explore given its build requirements.

<oriansj>And thanks to Michael Schierl's wonderful guile bootstrapping work; guile is just a better option on the higher and with Mes.c being a better option on the lower end; there just isn't much bootstrapping value one can get out of prescheme these days.

<stikonas[m]>I guess these days the question is not whether it (more generally, not just prescheme) can be used for bootstrapping but whether there is any benefit over what we have. I.e. implementation that is easy to understand, more cross platform support, possibly much faster, though this is not as important.

<oriansj>it doesn't even need to be any better; it just needs someone willing to do the work and find its place as a possible path in the bootstrap chain.

<oriansj>and if one is willing to do that work and puts effort into making it better; it'll eventually become a useful tool that other people may choose to use.

<oriansj>if anything, it'll make the bootstrapping ecosystem richer and give people more freedom of choice

<stikonas[m]>Well, if somebody is willing to do the work then certainly

<oriansj>as who does decides ^_^

<stikonas[m]>Anyway, something smaller than cc_x86 might be interesting

<stikonas[m]>Especially if high level prototype of cc_x86.c could be ported to that simpler thing

<oriansj>well I was more thinking of porting mes.c to the typed scheme

<oriansj>and boy am I having an educational experience doing so