<stikonas>next time for M0 hex encoding will be a bit easier since I won't have to combine words, can just leave everything with .WORD <stikonas>on the other hand writing assembly version will take longer... <stikonas[m]>Interestingly, hex2.hex1 used exactly 62 labels, so each alphanumeric character was used <oriansj>stikonas: well you could also use digits too (it works fine in hex1 and hex2 but not in M0 or M1) <oriansj>well every ascii char works in hex1 but not in hex2 which actually cares about the specials <oriansj>So there are 127 (including \x7F DEL) possible hex1 labels but using them will break on hex2 <oriansj>but yeah 66 is the reasonably functional hex1 limit <oriansj>or :< or :> or :$ if one wants a major debugging headache <stikonas[m]>Anyway, it was enough even for riscv which is longer than hex2 for other arches <oriansj>stikonas: I must say you have created the most impressive hex2 in hex1 ever written and you should feel quite proud. <oriansj>xentrac: wouldn't work in hex1 but :-D will <xentrac>I wonder if it would be worthwhile to make hex1 labels fixed 2 bytes instead of 1 <xentrac>because if stikonas[m] has to go to 63 he's going to end up with :@ or :! or something <oriansj>xentrac: If one needs more than 127 functions/labels to write a minimal hex2. Then the architecture might not be bootstrappable. <xentrac>someone might have to fix a bug at some point, stikonas[m] <xentrac>oriansj: wait, are you considering using :^R and :^T? <stikonas[m]>Most likely any bugfix can be done without introducing any new labels <oriansj>xentrac: all ascii are valid in hex1 as hex1 labels <xentrac>yeah, but valid is one thing, tolerable is another ;) <oriansj>in theory all 8bit values are also valid hex1 labels. However then we run into a bigger problem. <oriansj>petscii and other character sets are certainly possible but audit across diverse architectures becomes a little more complex <oriansj>stikonas: specifically 1 byte as unicode might require multiple bytes for a character. <oriansj>and yes using the delete character is absolutely valid in hex1 but a bitch to audit; so it would be flagged by sin <stikonas>anyway, I can't imagine any arch requiring more complicated hex2... <stikonas>the only way you can make it more complicated is to have more different instruction formats <oriansj>stikonas: and they only have ~!@$%& to work with. and % and & are standardized for 32bit relative and 32bit absolute addresses. <oriansj>So if one can't encode the jumps and calls needed in 4 different formats; then the architecture is the problem. <fossy>libunistring-0.9.10: build successful <fossy>now i just need to check chroot mode works then this massive PR will be ready <oriansj>fossy: Miracles of hard work. Nicely done <xentrac>stikonas: moreover, to have more different instruction formats without which you can't write the next stage <oriansj>xentrac: well the instruction formats supported in hex2 are only the jumps, calls and the loading of absolute addresses. M1 can support alternate instruction formats for the loading of immediates and stack offsets <oriansj>for example one can work around the lack of an instruction format by loading a 32bit immediate and immediately jumping over it. (or 64bit if you so decide) <oriansj>it is certainly inefficient (especially in architectures that don't support PC relative loading) <oriansj>like copy PC to regisyter, load with an offset and jump over <oriansj>or in less reasonable architectures: copy the link register to a register you can use, push the link register value, do a call over the immediate, copy the link register to a register you can use, load the immediate, pop the link register value, copy the value back into the link register. <oriansj>Because you know 24bit instructions are so much more efficient than a 48bit instruction when it comes to loading a 32bit value.... <oriansj>oops I forgot the assembler had push and pop as pseudo-instructions and it was actually store and and add immediate instruction; subtract immediate and load instruction. <Hagfish>they've actually written the code to make binary transparency work at the distro level <Hagfish>no comments on HN yet, but please add any helpful remarks you can think of to encourage discussion there <oriansj>just need to do updates over tor to ensure you can't know who is recieving your evil updates ***edf0_ is now known as edf0