<oriansj>(,(string-append "mov____%" r1 is what you would be searching for <oriansj>correction (,(string-append "mov____(%" r0 "),%" r2 sort of thing (r0 and r2 might be the wrong names) <oriansj>in short, at runtime the values are resolved to si or rsi <oriansj>and M1 knows nothing that isn't EXPLICITLY DEFINEd <oriansj>rickmasters: you are right about memcmp; it is currently returning the number of matched bytes rather than zero <oriansj>now, just to do some slim tweaks and I think my gentoo install procedure will be complete and functionally identical to all the other distros <oriansj>(or I can integrate stikonas's work into the procedure and cover bits like mpv) ***stikonas_ is now known as stikonas
<oriansj>hmmm either there is an off-by-one error in glibc's memcmp or I have an off-by-one error in my modified memcmp <oriansj>so that one can do memcmp with motherhood and motherfucker, which if we are only comparing 6 or less chars should match. <oriansj>but according to glibc's memcmp it is 7 or less chars should match <rickmasters>oriansj: my testing shows both your implementation and glibc match at 6 and return a value > 0 for length 7 <rickmasters>oriansj: the difference is, for length 7, yours returns 2 and glibc returns 1, but it appears that any value > 0 is correct for that test case <ekaitz>hi! is there any reference file for the M1 macro syntax? <ekaitz>oriansj: okay so it's just that there are a couple of instructions missing in the .M1 definition <ekaitz>stikonas[m]: i wanted to know the syntax of the words, but I think I just have it right <stikonas[m]>It differs between stage0-posix, mes and stage0-uefi <aggi>minor notice: with both perl and python bootstrapping and/or cross-compilation those are a major trouble-source <aggi>python doesn't bootstrap/compile with tcc-toolchain, perl required roll-back to v5.8 to pass with tcc-toolchain, this old perl-version didn't support easy cross-compilation etc. <aggi>for another reason, decided to have a look at vis-editor, which optionally supports some neat Lua integration <aggi>and guess what, Lua scripting language: it compiles, cross-compiles, passes with tcc-toolchain, static linking, no problem <aggi>Lua doesn't require GNU-buildsystem (autotools/automake), hence no dependency against Perl with this <aggi>Oasis Linux, utilizes Lua for their package-management, instead of python which gentoo needs <Hagfish>Lua seems like quite a clean language/ecosystem, from what little i've seen of it <Hagfish>does it really have minimal build dependencies? <Hagfish>i wonder what architectural values the people behind it had, and how to encourage other communities to adopt them <aggi>seems so, i tracked this with gentoo-portage however, and plan for moving to and forking Oasis <Hagfish>yeah, Oasis is an intriguing choice. i'd not heard of it before <aggi>another noteworthy detail: different licensing with many of those, MIT instead of GPL <aggi>vis-editor seems neat too, i'll remove vim, and switch to vis <aggi>and i'll refine the tcc-toolchain profile, to avoid all python/perl/bashism/autotools/automake/gcc/binutils entirely <Hagfish>that does sound much simpler to reason about <oriansj>ekaitz: The syntax of the words is whatever the developer prefers to use/generate. As long as you have a matching DEFINE statement, you can use any syntax rules you like. But as you are working with mescc; I strongly suggest matching the existing generation rules in as.scm (until janneke writes out proper syntax guilelines for mescc) <ekaitz>oriansj: ok great! I'm just adding some instructions that already existed so it's just following them <ekaitz>I think I solved that already :) <oriansj>aggi: sounds like Oasis developers might find the live-bootstrap and stage0-posix work quite interesting as it will allow them to drop their bootstrap dependencies further. <stikonas>well, live-bootstrap should soon have modern toolchain <stikonas>once autogen is added, we'll probably update to the latest GCC <oriansj>stikonas: indeed but that doesn't mean they can't use the TCC bootstrapping bits <stikonas>sure, they can, I'm just pointing out that basically any distros can use it as bootstrapping base soobn <stikonas>well, maybe we need to add more languages, e.g. python... <stikonas>of course we still have non-bootstrappable stuff like GHC <oriansj>stikonas: indeed live-bootstrap makes the perfect bootstrapping base for many distros. <oriansj>and yeah a few more languages and build tools and then bootstrapping distros becomes just a question of which minor steps to add. <aggi>to avoid a misunderstanding, i do not intend to lock-out bootstrapping/cross/compilation of GNU-buildsystem/toolchain <aggi>hence the trouble, for example, with perl-5.8 and tcc; tested various variants of bootstrapping/cross-compilation with tcc/gcc <aggi>i am not concerned about GPL either, it's is only technical reasons, i think the outlined approach has advantages <aggi>i'll keep the gcc47/c-only toolchain profile frozen/archived, as i explained <aggi>and with tcc-toolchain, gradually refine the profile with stricter criteria applied <oriansj>aggi: you have a technical preference, that is pretty standard around here. I've been understanding your messages as your discovery of the current limits of tcc only environments and possible improvements. <aggi>to see, what remains, if python/perl/bashism/autotools/automake/gcc/binutils are removed entirely <aggi>tcc isn't the main limitation though, the major trouble sources orignate elsewhere, which i think are GNU-buildsystem/toolchain and their dependencies themselves <aggi>initially i nailed down this: no-c++, then tcc-toolchain only, and finally no autotools/automake etc.; for technical reasons <oriansj>well, there are only 3 major points for limiting of a build: The compiler, the library and the build tool. <oriansj>and autotools and the like could be replaced for many pieces (as we know the state of the system at all times) <aggi>components, such as vis-editor, dvtm terminal multiplexer, bearssl, may suckless.org goodies do not rely on autotools or any replacement <oriansj>aggi: even a shell command would be a replacement <stikonas>well, autotools is replaced with handwritten makefiles early in live-bootstrap but it's not particularly pleasant thing to to either (especially for bigger software like perl) <stikonas>because you have to manually specify all compiler defines that autotools does that for you <aggi>lua, ships an optional configure.in, seems the developers, intentionally, did this <aggi>of cause, the test-cases of mine are limited, nonetheless those do cover various cross/compilation paths with tcc and gcc <aggi>and without autotconf, lua cross/compiled with with tcc and/or gcc <aggi>had to rewrite the gentoo ebuild, as usual, with the many of 300 ebuilds in my overlay, to address such types of problems <aggi>which i am tired of and not willing anymore to bother with, hence removal of autotools and see what remains <achaninja>yeah, the instructions in the readme should work - though my memory is hazy - I was trying to get from stage0 -> tcc -> qbe + cproc -> musl toolchain <achaninja>I got a mostly working qbe that was linked with meslibc <aggi>i didn't yet arrive at the stage0 -> tcc phase for review <aggi>i am concerned with tcc -> see what remains without GNU-buildsystem/toolchain <aggi>and yes, currently there is a circular dependency remaining, against GNU-binutils for musl-libc assembly <achaninja>well I wrote an assembler that can assemble all of qbe + cprocs output <achaninja>Anyway - I was trying to experiment with ways to avoid tcc <aggi>another concern with this, is an exclusive vendor-lock against x86/64 <aggi>hence i am testing with arm-tcc <aggi>decided to include lua/vis-editor with the gcc47/c-only profile, which is frozen/archived <aggi>the tcc-toolchain verification of cross/compilation, too will be useful to any other alternative compiler, such as cproc <aggi>however, i decided to refine the tcc-toolchain profile from scratch, without any GNU-buildsystem/toolchain dependency <aggi>need to finish testing, vis-editor/lua; then tcc-toolchain from scratch, as outlined <aggi>anyway, sorry for the noise; achaninja i noted your git-repo for review, re-integration of musl-libc and/or mes-libc without any GNU-binutils dependency is on TODO still <aggi>the musl-libc patches available, are exclusive to musl-libc, i try to avoid such an exclusive vendor-lock <aggi>lua interpreter, is another test-case, to see if mes-libc sufficed with it, and if this passes with arm-tcc toolchain ***attila_lendvai_ is now known as attila_lendvai