<OriansJ>janneke: why is mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz 275KB when if one goes into mescc-tools-seed; tar cavf foo.tar bin/blood-elf bin/get_machine bin/hex2 bin/kaem bin/M1 the result is only 127KB and when xz'd it is only 16,924 Bytes? <OriansJ>and in fun news mes-m2 when xz'd is only 25,684bytes <fossy>hm, does mes libc provide getopt? <fossy>can i please have some help? <fossy>I keep getting 'tcc: error: undefined symbol 'getopt'' trying to build bash 2.05b <fossy>but i am still getting the error <fossy>Also is it possible to run guix bootstrap from a non guix system? <fossy>just compiled getopt.c in with it <janneke>OriansJ: yeah, that's BIG -- weird?! <janneke>fossy: yes, we need getopt for ... i should have documented that <janneke>fossy: i'm sure you have seen that the tcc bootstrap.sh script builds libgetopt.a, from mes? <janneke>the modification you to the bash makefile '-lgetopt' should pick that up <janneke>it's often easier to improve your understanding by looking at a on a working recipe <janneke>fossy: yes, of course you can build the guix bootstrap binaries from a foreign distro <janneke>the guix build system is a closure and builds in containers <janneke>that's why it is superior to (bootstrap) development: no leakage and portable <janneke>fossy try: ./pre-inst-env guix build -e '(@@ (gnu packages commencement) bash-mesboot0)' <fossy>i am primarily doing everything from the guix recipies <fossy>I think its because I have weird environment <fossy>Portable environment is very hard <fossy>OriansJ: how important is it to you that the bootstrap is run in any environment? <fossy>I would like to containerise this <fossy>I will investigate... I dont want more dependencies <fossy>janneke: how do you build in containers without an extra seed? <janneke>fossy: instead of -lgetopt, did you try: adding /path/to/tcc-built/lib/libgetopt.a <janneke>fossy: of course, a proper, fully clean build should run fine in a dirty environment <janneke>it's just that i've done that for too long and i'm done with it <janneke>esp. done with debugging all kind of weird packages hardcoded /usr/incude, /usr/local/foo nonsense <fossy>janneke: well thats the thing <fossy>I dont want to have to patch all of that <janneke>-l asks tcc to find the library, see if if you provide it; it works or not -- you can bisect further from there <fossy>like im already seeing /usr/bin/install being used etc <fossy>janneke: what containerisation method does guix use? <janneke>the really *great* thing (NOT) about that is that ./configure (and don't get me going a bout cmake ftm) could use /usr/include and you'd get apparently correct results <janneke>only if you ugrade your system, or try somewhere else, you cannot reproduce your result <janneke>fossy: it uses chroot, clone and linux namespaces <janneke>the build daemon is currently still forked from nix, which is great, but reepca is carrying the torch on the rewrite in guile <fossy>janneke: how much of this is implemented in scheme? <janneke>yeah, so only the build recipe is scheme; the containerisation is in c++ <janneke>not ideal, but pragmatic -- "it work" <janneke>that's why in the guix build recipe's (esp. hand-crafted "trivial-build-system"), you'll see guile modules listed for build that need to be injected in the container <fossy>it dosent want to run ./anything <janneke>you have created a "nice" opportunity for yourself to relive much of the fun puzzles that i found ;-) <janneke>and doing us all a great favour by documenting things what i failed to note *janneke likes scripted documentation a lot <janneke>someone could create a text adventure <janneke>"there are laying scripts around, some of them executable" <janneke>"you are overwhelmed, there are even X11 settings and things that look like code" ***ChanServ sets mode: +o rekado_
***bauen1_ is now known as bauen1
<OriansJ>janneke: it looks like you are using gcc built version of mescc-tools for the mescc-tools-static, rather than the bootstrapped mescc-tools-seed version <OriansJ>fossy: portablity of the bootstrap comes in 2 forms, exact same code running everywhere (M2-Planet and up only) easy to port to any arbitrary operating system and hardware (below M2-Planet only). And the form for portability matters a great deal. <OriansJ>The lower levels don't need containers because they literally are blind, deaf and ignorant of the environment they are in. <OriansJ>only pieces written in M2-Planet (or above) can even know there is an environment and change their behavior in anyway. <OriansJ>as containers only matter in regards to applications that change their behavior relative to the environment they are in. <OriansJ>janneke: however we could just simply drop that binary when dddddd finishes slow-utils, which will work everywhere mes-m2 does. <janneke>OriansJ: ah yes, i'm using the regular guix bootstrap policy here <janneke>yes, and i've chosen to not refresh the bootstrap binaries *janneke heads back to #libreplanet <OriansJ>janneke: well the only refresh that would make since is reduce the bootstrap binaries to just guile (prior to the mes-m2 switch of course) <janneke>"just" drop mescc-tools and mes bootstrap binaries <OriansJ>Then the final piece just becomes mes-m2 as a drop in replacement for guile. <OriansJ>as guix removes all non-scheme pieces thus no binaries needed for guix outside of guile. <OriansJ>bauen1: helps us get a POSIX bootstrappable from M2-Planet, completing the final loop on x86/AMD64/armv7l/aarch64/etc <OriansJ>Then I go off and bootstrap the hardware itself finishing the final possible loop. <bauen1>OriansJ: you're in luck, my school is closed for 5 weeks, so i have quite a bit of extra time <bauen1>OriansJ: how do you plan on bootstrapping the hardware ? <bauen1>i've been toying with the idea of building a 65816 based computer (so you have "simple" parts you can verify) <bauen1>equipping that thing with an mmu (either 74xxx based or cpuld) and an spi bus would create a "simple" system <bauen1>simple as in you only have a few chips where you need to verify correct functionality <bauen1>that should allow for a "modern" operating system that allows you to 1. write code, 2. build the code (possibly for a system that requires binary blobs to actually work) <bauen1>the 65816 is also easy simple enough to program that you can hand-assemble a simple monitor program and then write it into an eeprom by hand <bauen1>sadly it appears that the tooling around the 65816 is a bit lacking <OriansJ>bauen1: well the original plan is to first implement knight in FPGA and then individual logic gates. (possibly individual transistors if I get cheeky) <OriansJ>afterwards, a libresilicon implementation will enable cheap verfication by arbitrary parties <dddddd>OriansJ, what's the point of range_check in M1-macro.c given that we bitwise-and the value (to discard out-of-bounds bits) just before using it? <OriansJ>This also gives us the power to change the ISA in arbitrary ways to simplify hardware implmentations and enable a long term future growth of the knight ISA. (I was think thinking of specifying a block of Opcodes for experimentation <OriansJ>dddddd: good point, I should have moved it prior <OriansJ>dddddd: as we do want to catch values too large to express in the number of bits <OriansJ>aka !-270 should throw an error not silently be wrong <OriansJ>aka accidential behavior should never occur in mescc-tools <dddddd>So, the bitwise-and wouldn't be reached and that's what might be removed, isn't it? <xentrac>bauen1: have you been watching Ben Eater's video tutorial series on building a 6502-based computer? he seems to know what he's talking about — I haven't caught him in any errors yet <OriansJ>dddddd: approximately correct; but x86 behaves badly with negative numbers in gcc <dddddd>Well, I guess that's not a problem for M1.scm so I think I won't replicate with "double check". <OriansJ>The and truncates the leading 1s and enables correct behavior <dddddd>OriansJ, also I don't quite understand the checked range (for example -128, 255). It seems to cover both(!?) the signed and unsigned ranges at the same time, which aren't possible at the same time... <OriansJ>as far as M1 is concerned both are values that fit in 8bits <OriansJ>with the meaning to be determined by the instruction reading the !value <OriansJ>for example JE8 !123 is signed but LOADUI !255 is unsigned <OriansJ>so unless we want to change how M1 works; it is unfortunately something I don't have a good solution for. <OriansJ>as M1 is largely assume the programmer only writes perfect code sort of language. <OriansJ>with only a handful of basic error checks to catch common bugs (like double DEFINEs and immediates too large) <dddddd>I guess a solution is to have different prefixes for signed/unsigned. <OriansJ>which increases the complexity of the M0 implementation in hex2 <OriansJ>or we do something like !S123 and !U255 and have M0 just ignore the first char <OriansJ>but that would require matching changes in MesCC, M2-Planet and mescc-tools (and some backporting to mescc-tools-seed by me) <OriansJ>So we could do it but it'll require a combined effort of you, me and janneke to ensure it is done universally. Provided janneke is on board with that change. <OriansJ>as such a rule would require a change in hex2 to forbid labels like :S123 and :U45 <OriansJ>as then @S123 and %U45 would be ambigious <dddddd>Different prefix-symbol seems to cause no ambiguity. Anyway, I don't know if any change is needed, other than clarify the issue in the documentation. <dddddd>The size of int might generate some confusion, I guess. I think we're expecting at least 32 bits sized ints. <dddddd>... which are signed, for more fun. <dddddd>As in range_check does 'if(4 == number_of_bytes) return;' blindly. <dddddd>express_number, numerate_string and friends are all using signed ints and even if they were unsigned they can't store, say, 3 bytes if int is just 16 bits (allowed by spec AFAIU). <dddddd>16777216 is off by one in range_check <fossy>OriansJ: precisely, I am talking about past mes-m2 <fossy>because I am faced with a choice here: <fossy>1. Containerise things to ensure that we don't use anything from the host <fossy>2. Go through every build system in depth to ensure that it will not reference anything from the host environment ever <fossy>imho containorizing is very doable <fossy>but then again build system work is better <fossy>the more I think about it the harder it will be to do build system stuff especially for crap like gcc <fossy>Proot would be a good option, if I can get something like that working <fossy>wonder if tcc can compile an early version <OriansJ>fossy: well if one strips out the environment to a minimal subset required; applications that attempt to use PATH will find nothing to use but we will need something like containers if we wish to hide files from the applications. <OriansJ>although, stripping that code out would make the behavior more universally consistent. <OriansJ>personally, I am of the belief that we should stop playing stupid games to get broken shit to work. <OriansJ>containerization and other tricks are fine for badly written applications when one has a fully bootstrapped Guix foundation but we really need to give up on the belief that we should accept badly written programs as they are. <OriansJ>It is why I believe janneke did the right thing when he forked TCC to enable MesCC to be able to bootstrap it but I feel he didn't go far enough to convert TCC into something worth keeping in the bootstrap and thus believe extending MesCC to be able to bootstrap GCC directly is ultimately a superior goal. As bootstrapping is less about playing well with others and more about just doing the right thing; even if it means you have to go it <OriansJ>Write code that solves your own problems and make yourself happy first, let others choose if they agree with you or not on those shared classes of problems. <OriansJ>Compromise only when it results in far more gains than loses but never sacrifice your goals; ever. <fossy>OriansJ: Fair enough, that makes a lot of sense <fossy>doing things the Right Way is better than doing it the bad way in the long run, even if it will take longer to make <OriansJ>fossy: well I spent 2 years being told it was impossible to write a C compiler in assembly and tried literally everything else (a FORTH and a Lisp) <dddddd>M1.scm now has decent range-check. <OriansJ>fossy: multiple times for different architectures <fossy>k i need to add unset support to kaem <fossy>crap, I never did those fork tests <dddddd>But M1-macro.c is rough on the edges about that, AFAIU. We'll see how it works when we flip the checks. Now is kind of broken (accepting values that M1.scm rejects). <OriansJ>dddddd: we will slowly fix all these details <dddddd>OriansJ, what do you think about the int size I pointed out earlier? <OriansJ>dddddd: it is a compromise as it would be quite difficult to support 64bit values on 32bit processors <dddddd>... or 32 in 16 bits C implementations, I guess. <OriansJ>the reason why M1 and hex2 limit themselves to 4GB is because it is large enough to support rather serious applications but 64KB is not <OriansJ>one can do a serious 32bit processor in 15K transistors <OriansJ>and I think RMS was right to not bother with 16bit processors when doing real important work. <dddddd>Note that I'm not talking about the hardware implementation, but the C int (which has some relation to hardware, but it's not all). <OriansJ>I have no illusions about the possiblity of 8/16bit processors being able to build GCC, the best they could do is run cc_x86 if we work really really hard for it <dddddd>Sure, but I think none of those compromises you did are documented. <OriansJ>dddddd: very true, I must admit documentation was been one of my weaknesses in the project thus far. <dddddd>What's the point of the M2-Planet ports to Z80 / 6502? Seems to be conflicting messages. <OriansJ>dddddd: more of a personal stretch goal; as a virtual machine (like sweet16 but 32bit) upon them could be used with some cleverness to enable something more impressive <OriansJ>as I want as many arbitrary pieces of hardware to be able to perform the M2-Planet stage of the bootstrap. <dddddd>I'm missing something, because I think we're again on square one (of the 32 bit compromise and the int size of C/M2 code). <dddddd>Now, it's not GCC, but M2-Planet. <OriansJ>well that is the thing, should I add prefixes for 64bit, 128bit and 256bit values to M1 and hex2? Why stop there? we could do prefixes for 512bit or 1024bit values <dddddd>I don't think we need to think about them. The 24 bit prefix is already there. What about it on 16b (or less) archs? <OriansJ>well in assembly it is easy to add support for 32bit integers on 8bit architectures (if one has overflow instructions) <OriansJ>simply allocate 4bytes and use 17instructions per integer operation; it'll be slow but it'll work <OriansJ>because C doesn't do integer overflow correctly. <OriansJ>aka i = i + 1; => why no overflow flag to use? <OriansJ>vs add.cio R0, R1 1 => adds in carry flag and sets carry flag on overflow <OriansJ>It is why C without inline assembly support is not worth the trouble. <OriansJ>C is only good when it is able to punt to assembly when real performance or real work needs to be done. <OriansJ>C's greatest strength is it allows you to achive "good enough" results with minimal effort and "reasonable" results when you absolutely must. <OriansJ>cc_x86.s is literally 24hours of work to get "good enough" results. but to get "reasonable" results; major changes could need to be done in M2-Planet to generate anything close to approximating "reasonable" performance in its generated binaries. <dddddd>So, an imaginary M2-Planet for 6502 would use 32bits "int" (with asm from the compiler slow and so --not user inline asm). <OriansJ>well M2-Planet is currently 145KB it can't run in 64KB <dddddd>Imaginary, so to see if I really understand the invariants we're not asserting.