<stikonas>this probably gives away what part of cc_amd64.M1 I'm working on ***xerox__ is now known as xerox
***xerox is now known as edi
<stikonas>well, like the post says, fibonacci is not the best benchmark <stikonas>I guess especially because the easy way of calculating it (recursion) is the slowest <aggi>made another decision today, moving to oasis linux <aggi>which i hope, has some benefits, related to GNU-buildsystem removal <muurkha>yeah, I was thinking maybe Dhrystone or Bytemark or something like that would be a better benchmark. <aggi>because, Oasis Linux replaced all pre-generated configure/makefile and configure.ac stuff with their lua-based declarative package-management <aggi>sorry, didn't mean to interrupt <muurkha>aggi: nice, sounds like a lot of work. have you implemented Lua? it's a really nice litle language <aggi>no, i only tested lua integration, that it compiles/cross-compiles and statically links with GNU-toolchain and tcc-toolchain <aggi>and lua doesn't require any GNU-buildsystem either <muurkha>stikonas: I tend to use dumb fibonacci because of ease of use; you can hack it together in any language you know in a few minutes and get a microbenchmark. just that sometimes it doesn't tell you anything useful <muurkha>it's true, Lua is easy to build and doesn't rely on autoconf or much of anything <aggi>just a coincidence, because i moved to vis-editor (instead of Vim), and vis-editor too got some neat lua-support <aggi>oasis-linux too utilizes lua scripts for their package-managend and build-system, and alltogether this avoids MANY bootstrapping issues <aggi>however, i need to move my entire patchset for tcc-toolchain specific over there, cleanup the entire oasis package tree <muurkha>my theory with HandAxeWeb was that literate programming doesn't have to require a lot of code <aggi>because oasis contains too many components which don't pass acceptence criteria still <aggi>and, oasis moved to linux-5.16 already, while i intend to roll-back to linux-2.4 with tcc-toolchain <aggi>relevant aspect with bootstrappable.org being, as said, to avoid many bootstrapping issues GNU-toolchain and GNU-buildsystem have <aggi>since the lua-based scripting for package management replaces all configure/makefile based GNU clutter, that's just too appealing <aggi>in recent days, i had begun tracking full removal of it, GNU-buildsystem, and as expected the entire dependency tree had fallen apart <aggi>i already did remove GNU-toolchain dependencies and entirely replaced it with tcc <aggi>(except for musl-libc, which is a separate mile-stone) <aggi>however, the development HOST itself is rigged, with GNU-buildsystem involved <aggi>for example, i will need git, and oasis linux already did re-implement the entire makefile/configure stuff, with their lua-scripts <aggi>too, they already did fully integrate bearssl, netbsd-curses; and given the gcc47/c-only toolchain with gentoo-tooling remains frozen and archived <aggi>i am not willing to invest any effort anymore at that frontline <aggi>GNU/gentoo, that's all burned soil, impossible to salvage <aggi>oasis linux package tree, is missing many relevant packages still (lynx browser, nfs-utils, isofstools, cdrecord, rsync etc. etc) <aggi>however, with GNU-buildsystem remove for the tcc-toolchain profile, those components need full re-integration anyway, regardless of any package manager chosen <aggi>and, of cause, oasis linux tree too is missing all patches which i maintained in my c-only tcc-profile on gentoo build-host <aggi>that's two different questions, to be precise. Gentoo-specific issues (bashism, GNUism, python), and GNU itself <aggi>if you accept the argument, Perl,Python,Bash must be removed, it's obvious there is no place to go with Gentoo <aggi>besides the fact, i blocked at gcc47/c-only which isn't maintained with any gentoo-profile, and my overlay had blown up to 300(!!!) ebuilds i needed to track and patch <aggi>this two answers the question, what the problem with any other "distro" was, if they needed any of the mentioned components <aggi>btw.; i do not object to any "progress" made with GNU/linux or however you name this <aggi>i object to a _stable_ development base was rigged itself <aggi>including linux kernel itself <aggi>blocking at gcc47/c-only is necessary, yet insufficient, since when i realized GNU-buildsystem itself (autotools/automake, pre-generated configure/makefiles) is rigged <muurkha>why would you want to remove Perl, Python, and Bash? I thought you just wanted to remove C++ <aggi>then i swapped, to tcc-toolchain, and refined the entire dependency tree, realizing, perl-downgrade to v5.8, which doesn't cross-compile <aggi>i think this was the final stroke to Perl and with it GNU buildsystem gone <aggi>next one, Python: this one, besides the buildsystem clutter, relies upon ASM, which tcc-toolchain assembler couldn't digest <aggi>this was the final stroke to Python (besides many other problems with it) <aggi>Bash? bashism, non-posix. <muurkha>oh, I remember you had that problem with tcc asm before. I wonder what the problem is <aggi>none anymore, i removed python <muurkha>why does Python need assembly to compile? <aggi>because it "optimized" with assembly <aggi>which is ok, if it didn't need GNU binutils and with it a giant dependency graph of flawed software <muurkha>I mean I ported Python to NeXTStep on HPPA one time in the late 90s and I didn't have to rewrite any of it in PA-RISC assembly, though admittedly it wasn't the first HPPA port <muurkha>too bad I never did the work to contribute that back to the core <muurkha>I think that if you want to get rid of all flawed software you are going to have to start with a much more minimal set than you're imagining right now. like, Metamath Zero, maybe, and seL4 <muurkha>you'd have to bootstrap OCaml to get Coq to check the seL4 proofs <aggi>i am aware of the limitations <aggi>i'll certainly not bootstrap yet another interpreter <muurkha>but OCaml isn't really that terrible a language to write a new implementation of, I think <aggi>and i won't praise lua and oasis linux yet, i only made the decision today, i'll continue efforts based on their tree and package management approach <aggi>moving my patchset to their tree, cleaning their tree from undesireable stuff, roll-back to linux-2.4, tcc-toolchain integration with oasis, musl-libc support with tcc-toolchain <aggi>that's still very much work, and too it was alot of thinking, before i made that decision <muurkha>it only took a few hours and 212 lines of Python to get to the point where it could interpret a fractal-ASCII-art-generating program <muurkha>it would have been easier (and run faster) in OCaml <muurkha>I called it "Caronte" because "Lua" is Portuguese for "moon", and "Caronte" is Portuguese for Charon, the moon of Pluto <muurkha>it's about a third the diameter of Earth's moon <aggi>anyway, that's some very simple rules to follow: no-c++ dependencies nowhere, no GNU-buildsystem (autotools/automake pre-generated configure/makefile clutter) <aggi>and then, see for yourself, how far to bootstrap things goes <muurkha>I feel like you can probably get Python and Perl to compile without C++ or autotools or automake <aggi>i feel like, even if, i don't want to <muurkha>I mean the reason I had to do any work to get Python running on NeXTSTep on HP-PA was that it wasn't using autoconf <muurkha>because it was already ported to HP-UX on HP-PA and NeXTStep on m68k <aggi>currently, i am in the comortable situation, of having archived a somewhat stabilized gcc47/c-only toolchain tree, together with power gentoo-tooling <muurkha>so if it had been using autoconf at the time, it would have just worked, but no, I had to edit it a bit <aggi>and, no need anymore to upgrade this anywhere, because the upgrade paths are blocked <aggi>this archived/frozen frozen profile, should proof sufficiently stable, for another 10years, and meanwhile, i don't care <aggi>if the move to oasis-linux,tcc-toolchain,linux-2.4 succeeds, that's fine, if not, i don't care anymore <muurkha>yeah, it sounds like you've found a promising new avenue to achieve your goals