IRC channel logs
2024-10-31.log
back to list of logs
<fotis>@nore: somewhere earlier in the same page, there is a reference to DawnOS apparently implemented in subleq, interesting! <fotis>@nore: what were the technicalities of preferring subleq over subneg? It's too far in time to remember what I was doing back then with it, but I recall that early algorithms were better to play with with subneg rather than others of the same family(-ies). <fotis>the decoding unit for subneg4 cpu was a very sparse 12x8 matrix which was implementable with a handful of TTL chips, and cascaded EPROMs for the ALU unit. The subleq implementation should be about the same complexity, so there you go! <[exa]>is there some language design/theoretical reading about M0? I read it's a pretty cool macro system but kinda searching for what the limits are <[exa]>(in particular, can the macros trigger evaluation of other macros?) <[exa]>(ok I assume not, finding there's also M1 and M2 :D ) <ekaitz>[exa]: M0 is just ELF files written as hex strings <ekaitz>[exa]: there's nothing really special about them (apart from the fact that someone had to come up with the idea) <[exa]>like, long story short, I'm bootstrapping haskell via a small vm that I've got in assembly <[exa]>made up an intermediate forth-like language, so kinda wondering if M0 or M1 would on itself be able to translate it <aggi>not an urgent question: which and if any was the reason for perl-5.6.2 instead of perl-5.8.6 (at the bootstrapping stage of perl with tcc/static) <aggi>i'm re-iterating over perl again, and 5.8.6 was the last-known that i could compile/link with tcc statically (except for some extensions that i missed for automake/autotools last time i tried) <aggi>i am not worried if i either perl 5.6.2 or 5.8.6 were salvaged for autotools support <aggi>i've just had perl on the hitlist of troublemakers for a little while, and rather avoided any further problems <matrix_bridge><Andrius Štikonas> [exa]: M0 is basically just string substitution with hex <matrix_bridge><Andrius Štikonas> Plus some support for encoding immediate constants... <matrix_bridge><Andrius Štikonas> Macros can't directly trigger other macros, it is one pass assembler <matrix_bridge><Andrius Štikonas> You could create something where you run M0 twice <matrix_bridge><Andrius Štikonas> aggi: cause 5.6 was sufficient for our purposes <matrix_bridge><Andrius Štikonas> We had to bootstrap pregenerated files from earlier versions of perl <aggi>ok, stikonas, then that's the difference: i picked the latest version possible with tcc, bootstrappable picked the minimum version, without any other side-effect known <aggi>trying to re-produce steps/perl-5.6.2 i'm digging into live-bootstrap currently, git-synced including all latest submodules <aggi>trivial question: is the current live-bootstrap version and it's submodules a known good baseline? there seems no git tags available for any. <aggi>another minor difficulty i am having, identifying how the bundled files config.h,config.sh and main.mk are merged into the perl-5.6 source tree during pass1.sh <aggi>it's not pass1.sh script itself which is copying those files into the perl source tree <aggi>i spotted the script-configurator.c already, that processes the steps/manifest; nonetheless it's a littly mysterious at first glance, to grasp the sequential logic of perl-5.6 step for example <aggi>i am not prepared yet to follow complete bootstrapping, but instead salvage parts to move those into the system-profile for tcc-toolchain support <aggi>i see, steps/helper.sh, however that's related to steps/manifest interpreted by script-generator.c, i'll find out <aggi>currently the tcc profile of mine is locked and trapped inside gentoo ebuilds/portage/crossdev still <aggi>bootstrappable scripting seems a decent candidate to converge and re-integrate with, to emit a complete tcc distribution <aggi>thanks, good to know master branch is mostly stable to rely upon. <matrix_bridge><Andrius Štikonas> cosinusoidally: that SSL issue is workarounded <mihi>[exa], multiple passes of M0 (constant number of them) are definitely possible, I used them in a project before but ultimately did not publish the result for reasons unrelated to M0. The tricky thing is to quote parts (in double quotes) that you want the second pass to evaluate so that the first pass does not mangle/touch them. <stikonas>aggi: and for sequential logic of each package, you should look at helpers.sh <stikonas>manifest just shows the order of packages <stikonas>it just runs functions called src_get, src_unpack src_prepare src_configure src_compile src_install src_postprocess src_pkg src_checksum src_apply <stikonas>and each package can override them as needed <stikonas>e.g default_src_prepare applies all patches, copies mk/main.mk file into the unpacked tree and copies everything from files/ <[exa]>stikonas, mihi: thanks for the hints, I guess I'm getting into the logic of the whole structure <[exa]>tbh I was thinking if I could beat something like primitive register allocation out of it, turns out yes but better not :D <[exa]>anyway, mihi: yeah I'm aware of blynn's compiler and MicroHS, I'm literally having a small quest of "how this would look without the C in the middle" <mihi>ah ok. feel free to follow that quest if you enjoy it :) <[exa]>there's a few funny minimal evaluators for haskell that are entirely un-C-ish, so trying to patch up something between full haskell and these to make it practical <stikonas>for haskell the hard bit I guess is reaching ghc <stikonas>smaller haskell compilers can be built I think <[exa]>yeah absolutely, ghc is an enormous single peak <[exa]>you can get 99% of the things with even smaller compiler than the MicroHS <[exa]>I don't like the combinator-based runtimes of these though, so trying the good old STG-directly-to-assembly <aggi>stikonas: noted, found this helper.sh already; currently stuffing the perl-5.6.2/pass1.sh into a gentoo ebuild for local testing; seems bison-3.6.4 output isn't compatible with whatever bootstrappable expects to build perl (bison-2.x it seems) <aggi>which raises another concern, what's considered "human readable" source code <stikonas>live-bootstrap rebuilds all bison .y and flex .l files too <stikonas>as first pass, you can just try without re-running bison or regenerating header files <aggi>perly.c emitted by bison-3.6.4 freaks out as follows (with a little more debug output from gcc): perly.tab.c:1681:13: error: unknown type name 'yysymbol_kind_t' <aggi>i'm not seeking advice on this, it is what it is <aggi>i'll give bison-2.x a try <aggi>that's three issues at once: (1) retaining perl/autotools support (2) bison-version required and, (3) related the readability of this <aggi>without regenerating, ... y.tab.c:1463: error: macro 'yyparse' used with too many args ... wherever that's coming from since i don't see any call to yacc perly.y anywhere in the Makefile <aggi>i'll give re-generating with bison-2.x a try <aggi>yep, already deactivated regenerating, and the build errored out later then <aggi>re-generating with bison-2.3 passes, and a few other issues following then