IRC channel logs

2022-07-15.log

back to list of logs

***onebitboi is now known as onebitboy
<stikonas>oriansj: I now have hex0.S for uefi/amd64, it works though still needs some optimizations
<stikonas>quite a lot of uefi overhead at the begining/end of the file https://git.stikonas.eu/andrius/stage0-uefi/src/branch/main/amd64/Development/hex0.S
<stikonas>but middle of the file is basically direct copy/paste from stage0-posix
<stikonas>and those uefi bits will mostly be the same in more complicated programs, i.e. in cc_amd64
<oriansj>We could simplify the read/write and remove the size and input/output labels with a minor tweak
<stikonas>and there are some stack optimizations that can be done
<oriansj>copy the stack pointer into rdx, push 1 onto the stack, copy the stack pointer into r8 and do a push. then we pop to get the byte and pop again to see how many are read
<stikonas>I first wanted to get something working and then do optimizations as it's much easier to debug
<oriansj>any reason why you do: sub rsp, 32 and add rsp, 32 ?? is it because the uefi expects a certain stack allocated?
<stikonas>it does although I'm not sure how much if there are fewer than 4 arguments
<stikonas>calling convention states that you push first 4 arguments to rcx, rdx, r8, r9 but you also need to allocated shadow stack space that uefi function can use
<stikonas>maybe we can allocate fewer than 32 when there are fewer arguments, but I'm not sure
<stikonas> https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170
<stikonas>hmm, I think we can allocate just 24 if we have 3 arguments
<oriansj>well we can do a test where we see if uefi overwrites anything on the stack; by pushing 0,1,2,3,4,5 and then on the return popping and comparing the values
<stikonas>well, it might be implementation specific...
<oriansj>good point
<stikonas>but now I think if we have 1 argument, then allocating 8 should be enough
<stikonas>it seems that space is for uefi function to save argument variables if it wants
<oriansj>well 8 arguments for a 64bit register size would be 64bytes not 32
<stikonas>well, 32 is for 4 arguments...
<oriansj>true
<stikonas>I think I can also remove stack deallocation after calling system->boot->exit()
<stikonas>I don't think it's ever reached
<oriansj>how could it be reached? unless something crazy is done for termination
<stikonas>yeah, I removed it here...
<stikonas>it's copy paste from earlier
<stikonas>initially I had just ret in the main function
<stikonas>but then I had to switch to exit() since I moved terminate into a separate function
<stikonas>or rather read_byte was moved to a separate function and it jumps to terminate
<oriansj>well if a return from main works, doing a pop then return would work too
<stikonas>yeah, I can try that
<oriansj>as call just pushes the previous address onto the stack and jumps to the target address. So popping will clear it off the stack and the return will use whatever is on the top of the stack