IRC channel logs

2022-07-16.log

back to list of logs

<stikonas>yes, that's probably simpler
<stikonas>just deallocate required amount of stack
<stikonas>set return value
<stikonas>and ret
<stikonas>ok, pushed this exit() to ret change
<stikonas>will do some other optimizations tomorrow
<stikonas>(or pull requests are also welcome)
<stikonas>oriansj: I've spotted a couple of bytes where we can cut size of hex0...
<stikonas>both on x86 and amd64 for stage0-posix
<stikonas>though one would have to redo hex0 conversion...
<stikonas>e.g. here https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0_x86.hex0#L102 we can use 85C0 (test eax, eax) intead of 83F8 00 (cmp eax, 0) and on line 106 we can similarly use 83FD 00 -> 85ED
<stikonas>let me see if I can spot any other optimizations
<stikonas>(oh and I've just pushed that read/write_byte optimization to stage0-uefi)
<stikonas>hmm, yes, I think I can reduce hex0 size a bit more...
<stikonas>and same read/write_byte optimization from stage0-uefi can go to stage0-posix...
<stikonas>oriansj: I now have 317 byte hex0 (built from M1 sources)
<stikonas>with just these simple optimizations, nothing super fancy
<stikonas>so already 40 bytes down
<stikonas>I'll do more tomorrow, hopefully will go under 300 bytes
<stikonas>and combined with kaem-optional, later I think we can go under 1 KiB
<Hagfish> https://www.guinnessworldrecords.com/world-records/25052-longest-number-sequence-memorized-in-one-minute-binary
<Hagfish>"The longest binary number sequence memorized in one minute is 270 and was achieved by Aravind Pasupathy (India) at the Kasthuri Sreenivasan Trust in Coimbatore, India, on 3 April 2015."
<Hagfish> https://www.recordholders.org/en/list/memory.html#bits-30min apparently if given 30 minutes a human can potentially memorise 6270 bits
<stikonas>fossy: maybe you can review https://github.com/fosslinux/live-bootstrap/pull/187 when you have some free time
<oriansj>stikonas: nice
<stikonas>oriansj: there is no hex0.hex2 for x86?
<stikonas>well, I'm encoding directly from M0 to hex0 right now
<stikonas>did one pass, got the right file size, now need to recalculate jumps
<stikonas>it's now 295 bytes long
<oriansj>nice
<stikonas>mostly simple tricks, for example instead of loading mov eax, 5; push 5; pop eax
<oriansj>well, we have been using unoptimized to ensure ease of understanding. So keep that in mind.
<stikonas>yeah I know, I always added clear comments and tried to only use simple tricks
<stikonas>e.g. xor eax, eax ; eax = 0
<oriansj>thank you ^_^
<stikonas>well, I'll do PR soon and then you can review if it's simple enough
<oriansj>of course
<stikonas>but it's quite significant reduction in binary size
<stikonas>though a lot of it is due to being less wasteful with zeroes
<oriansj>yeah, it was a very naive and simple implementation ripe for improvement.
<stikonas>oriansj: how do you want PR, first stage0-posix, then bootstrap seeds then update submodule or should I start with bootstrap-seeds
<stikonas> https://github.com/oriansj/bootstrap-seeds/pull/18
<stikonas>if changes above seem good, I should also port them to amd64
<stikonas>there is might cut even more bytes...
<oriansj>still reviewing but thus far looks good
<stikonas>should I push draft PR for stage0-posix with NASM and M0 changes (but without bootstrap-seeds submodule update)?
<stikonas>although hex0 files do have M0 strings in the comments anyway
<oriansj>and merged
<oriansj>well if we want to be consistent, they would need to be updated too
<stikonas>yes, I already have them updated
<stikonas>in fact started with them
<stikonas>oh but I first need to make PR to stage0-posix-x86
<stikonas>it's now a separate repo
<stikonas>ok, that one I can push myself
<stikonas>(for reference https://github.com/oriansj/stage0-posix-x86/commit/a53117074e8a35c499f34c0326913d45c3893d6a)
<stikonas>ok, changes pshed
<stikonas>oh maybe I should update README too that mentions 357 bytes
<oriansj>stikonas: well yes, I granted repo commit access to everyone who put serious work into an architecture
<oriansj>as I believe those who actively work to make things better should be free to do so.
<oriansj>unfortunately github doesn't support the ability to turn off force pushes which can rewrite history and delete progress
<stikonas>well, reviews are still good in any case, although you already reviewed interesting bits...
<stikonas>oriansj: I thought you can mark some branches as protected
<stikonas>let me check on one of my repos
<stikonas>oriansj: go to repo settings->branches->add branch protection rule
<stikonas>I guess only master/main branch has to be protected
***jackhill is now known as KM4MBG
***KM4MBG is now known as jackhill
<oriansj>and only against force pushes and deletes of the main/master branch
<stikonas>oriansj: I think I found a bug in rasm2
<stikonas>not a big deal, but one have to be careful with it...
<stikonas> https://paste.debian.net/1247414/
<oriansj>yeah, pretty common in all assemblers to have such bugs
<oriansj>as one will quickly see with: https://github.com/xoreaxeaxeax/sandsifter
<oriansj>but be careful running it on some processors as it has been known to brick certain hardware
<stikonas>well, this one is purely rasm2 bug, ISA docs or uses e.g. gcc work fine
<stikonas>s/uses//
<oriansj>well the ISA docs are wrong in several areas, such as is nop: 2,4 or 6 bytes in size
<oriansj>but assuming we stick to the GCC core x86 instruction set, then we should be fine as Intel and AMD seem to be generally very conservative on those encodings
<stikonas>yeah, I don't expect much/any variation amongst different CPUs
<stikonas>we are not using anything remotely uncommon
<stikonas>all the instructions are very basic
<oriansj>indeed
<stikonas>ok, hex0 for amd64 will be 405 -> 334 bytes
<stikonas>when I implement exactly the same optimizations
<oriansj>nice
<stikonas>still need to convert to hex0...
<stikonas>and then I can go back to optimizing hex0.S for uefi...
<oriansj>well decoding PE format details is less than ideal fun
<stikonas>yes, I can imagine...
<stikonas>and I guess testing is slow, since each time you need to launch qemu...
<oriansj>and deal with non-deterministic behavior in UEFI too
<oriansj>and a sick 2 year old who refuses to rest
<stikonas>well, UEFI can wait...
<stikonas>sick 2 year old is more important
<stikonas>ok, amd64 hex0-seed is now ready https://github.com/oriansj/bootstrap-seeds/pull/19
<stikonas>and https://github.com/oriansj/stage0-posix-amd64/pull/2