<stikonas>could go to 281 but not sure if that optimization worth it <stikonas>right now we have 'c' - 48; return; to convert ascii code to number. Could be replaced with just 'c' + 39 and let it fall-through to the next case, saves yet another byte but maybe too complicated <stikonas>though on the other hand 'c' - 48 assumes familiarity with ascii table anyway <stikonas>going down to 280 is possible but even more obscure... <stikonas>there are some other things that can be done but I'm not sure if we want them, so might be good to have a second opinion <stikonas>e.g. I think we can eliminate fin and fout global variables by storing those file descriptors in ecx, edx, but then we would have to push/pop them onto stack when calling Read_byte or write_byte <stikonas>oh actually esi register is completely unused, I think that could store e.g. fin <stikonas>and that alone brings hex0-seed to 271 bytes <stikonas>ok, got hex0_x86.M1 prototype to build to 264 byte hex0 <stikonas>and code is only 180 bytes, rest is elf header <Hagfish>"Guix takes a more radical approach: enabling independent verification of each step, building on reproducible builds, “bootstrappable” builds, and provenance tracking." <Hagfish>it's maybe a pity that "bootstrappable" still isn't accepted as a word, let alone a necessity for distros, but this extra exposure must help ***Server sets mode: +cnt
***Server sets mode: +cnt
<stikonas[m]>There are 2 more bytes that can be trimmed, but those are slightly more obscure, so maybe 254 is good enough <Hagfish>yeah, that's a nice round number to compare it to :) <Hagfish>apparently the old 80x12 punch cards weren't really designed to store arbitrary binary data, but they would be equivalent to 120 bytes per card <Hagfish>so if you wanted a good reason to golf it down to 240 bytes or less, you could give that as a justification :) <Hagfish>on the other hand, tweets can be 280 characters, so maybe that's a more meaningful comparison <stikonas>well, we don't need to print it on punch card... <stikonas>and 240 bytes would be very hard to reach <stikonas>possibly reaching 240 bytes would require cutting off some features.... <stikonas>i.e. only letting to use uppercase or lowercase characters, not both and only having one type of comments... <stikonas>so I don't think oriansj would want to go that route <stikonas>357 -> 254 bytes was done without sacrificing any features <stikonas>well, I still need to convert it from M1 code to hex0 code <stikonas>but with such small binary it's not too bad <Hagfish>yeah, sounds like there's nothing to be gained by trimming it more, and it's surprising that so many features could be compressed even this much <stikonas>since I've used the wrong immediate in two places, need 16-bit but in x86 M0 dialect it's @ and not ! prefix <Hagfish>a minor suggestion (or misunderstanding on my part): <Hagfish>i don't think that's intended to sound like a question <Hagfish>would it be more clear worded as "Where we are reading from" <Hagfish>(i know that text didn't change in the PR, so sorry if it's irrelevant) <stikonas>yeah, that's a comment from I think oriansj <stikonas>feel free to make another PR, should be easy to change it, since it's just a comment <stikonas>but probably best to have it in a separate commit