<dgpv>another 4 bytes easily shaved from stage0_monitor by using `TRUE R11` for toggle instead of `LOADUI R11 1`. There's straightforward way to shave maybe 12-16 bytes more by putting frequently used constants into registers, so I won't do PR just yet. <damo22>i read a recent blog post on guix.gnu.org regarding bootstrapping GCC. I had thought about this problem a while ago and came to the conclusion it would be nice if gcc could be bootstrapped with a minimal binary <damo22>but now that gcc requires a c++ toolchain to bootstrap it, what is the ultimate solution? <dgpv>re stage0_monitor: `LOADUI R13 0x600 ; Where we are starting our Stack` -- is it important to use 0x600 here ? Some constraint on initial memory ? Or , for example, 0x1100 can be safely used ? (that would be another 2 bytes shaved) <damo22>dgpv: stage0 is a virtual machine loop that executes one instruction at a time? <dgpv>it is a minimal firmware blob for a specific architecture specified in ISA_HEX_Map.org <damo22>can one install stage0 in flash on x86 for example? <damo22>who invented Knight ISA? it looks like a superset of ESIL from radare2 <dgpv>I don't know who invented it, I just started to hack on this a couple days ago :-) <dgpv>didn't feel a need to google for that <dgpv>but I think the idea is that ultimately you would want to bootstrap not only with your software, but also with your hardware <dgpv>and that ISA is designed to be easily implementable <dgpv>although it begs the question, if you do not trust your x86 hardware to bootstrap a compiler, do you trust it to run that compiler afterwards - backdoored hardware may change the code of your compiler in memory :-) <dgpv>even if you checked the hash of the executable file <janneke>damo22: the ultimate solution we can only guess at <janneke>damo22: so ... we will see a baby steps path towards a cleaner bootstrap; removing intermediate steps and reducing bootstrap seeds as we go <janneke>code-wise this has been a 2 person show for ~2 years, currently we have ~4/5 people working on it, but when this really starts to fly -- who knows? hex0 => MesCC++ => gcc-11 ? Why not? *janneke needs to go afk for a bit <damo22>have you heard of radare2? it implements ISAs in a vm-like way similar to your knight-vm <damo22>many architectures are supported <damo22>im trying to think how that project could help you guys if it had support for your ISA <damo22>but i think you already wrote one ***ng0_ is now known as ng0
<dgpv>there's probably no easy way to reduce further without refactoring the actual code logic <OriansJ`>dgpv: thank you for finding those additional savings. as for 0x600; it was simply a stack address past the end of the binary that I knew I was not going to hit and when the vm and the ISA document don't match; the VM is the correct one and one should put in a issue/pull request to have it fixed. <OriansJ`>damo22: the ultimate goal is not only trusted bootstraps but also fully trusted hardware; as libresilicon is important to the final goal <OriansJ`>dgpv: the only thing I can think to not use 0x1100 as the stack pointer is that it would increase the total hardware requirement from 1600bytes of memory to 4360bytes. we could also eliminate it entirely by pulling stack operations entirely like I did in stage1_assembler-0.s <dgpv>1024 would also work, for example <dgpv>0x600 seems like arbitrary number <OriansJ`>basically any number greater than the size of the binary itself will work <dgpv>must it be aligned by 4 ? <OriansJ`>no alignment constraints beyound byte aligned to 8bits <dgpv>only 4 bytes on stack is ever used <OriansJ`>but only if one uses the push32 instruction as pushr will be dependent on on architecture size (aka will push 8bytes on 64bit implementations, etc) <dgpv>you can do `READPC R13` and the stack will garble the initialization commands <dgpv>but you do not need them at this point <OriansJ`>so if one wanted to be really clever, one could set the stack pointer to zero and simply overwrite that memory after it served it's purpose <dgpv>stack pointer grows up ? <OriansJ`>hence why any address past the end of the program works <dgpv>or at the start of the program <dgpv>where the initialization commands reside <dgpv>you do not need them after init <OriansJ`>exactly if you know exactly how much stack is required <dgpv>in the case of stage0_monitor it is known (up to size of the word on particular arch) <OriansJ`>aka, if the stack will never be more than 16bytes in size; one could do 16bytes of initialization before stack operations and have no fear <dgpv>so should I do `FALSE R13` to init stack, or this will be too hacky <OriansJ`>dgpv: no need; all registers are initialized to zero on power on <dgpv>so that is another 4 bytes saved, then <dgpv>`0D00002F # FALSE R15 ; Our holder` <dgpv>that is also unnecessary init, then <OriansJ`>bingo (easy savings for others to find and fix) <OriansJ`>also if you look at stage1/stage1_assembler-0.s in the :hex function and compare it to the monitor you'll find another trick to save memory <OriansJ`>jsr_coroutine can be used to eliminate stack usage if you know you are going to bounce between known functions <OriansJ`>and the merge request "Reduce stage0_monitor by 10 bytes" forgot to update the checksum in bootstrapping\ Steps.org <dgpv>`ANDI R0 R0 0xDF` -- that is refactoring code logic for space savings <dgpv>at this moment I just went for simple things without changing the logic <OriansJ`>dgpv: completely fair and I must say excellent work <OriansJ`>although you might wish to add asm to stage0_test_scratch's dependencies, otherwise it will not be built when one does make clean test and they might hit an error (despite that all builds succeeded) <dgpv>I probably pause at this stage -- it was easy and fun, but tomorrow has to get back to my main project <dgpv>still have 30 min till my flight, will try to finish the remaining issues <dgpv>ok pushed the stack-at-zero / no-FALSE-R15 and fixes for hashes <dgpv>and the asm dependency in makefile <dgpv>forgot to mention that the stack usage is fixed and thus it is ok to set stack at zero <OriansJ`>dgpv: just let me know when you are happy with it and I'll merge after review <dgpv>OK I think the PR is ready <dgpv>btw, what is the thing with OR/AND in ISA_HEX_Map.org ? <dgpv>they are listed as 4-byte instructions, but the vm expect 6-byte and asm generate 6-byte <dgpv>`** Bit optimization group` <dgpv>`| B0 ab ii ii | ANDI a b ii ii | a = b & ii ii |` <dgpv>I was confused because other immediate-arg instructions all 6 bytes long with E1 00 prefix, and these are listed without prefix <dgpv>> PR has been merged -- cool ! <OriansJ`>The thing with ORI/ANDI in ISA_HEX_Map.org is that I missed them when I updated the implementation of the VM along with the assembler >.< <dgpv>so the issue is that documentation is out of date <OriansJ`>speaking of things I forgot to do; I really need to merge the AMD64 bootstrap +seed into mescc-tools-seed <OriansJ`>and get back cracking on slow-utils; speaking of which janneke hopefully you have tested the pieces completed so far and found them acceptable