home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 2,974 of 4,675   
   Rick C. Hodgin to Alex   
   Re: 64 bit stack alignment   
   29 Aug 17 15:19:01   
   
   From: rick.c.hodgin@nospicedham.gmail.com   
      
   On 8/29/2017 2:39 PM, Alex wrote:   
   > On 29-Aug-17 18:56, Rick C. Hodgin wrote:   
   >> On Tuesday, August 29, 2017 at 1:14:49 PM UTC-4, Alex wrote:   
   >>> On 29-Aug-17 17:07, Rick C. Hodgin wrote:   
   >>>> On Tuesday, August 29, 2017 at 11:14:38 AM UTC-4, Alex wrote:   
   >>>>> On 64 bit Windows, stack alignment on a 16 byte boundary is required   
   >>>>> before calling all except a leaf function. In the called function, the   
   >>>>> stack is 8 mod 16.   
   >>>>>   
   >>>>> Now, I'm struggling to come up with a way of doing it beyond this code   
   >>>>> (which I didn't invent, but I can't for the life of me remember   
   >>>>> where I   
   >>>>> found it.)   
   >>>>>   
   >>>>>      push   rsp   
   >>>>>      push   [rsp]   
   >>>>>      and    spl $F0   
   >>>>>      call   funkychicken   
   >>>>>      pop    rsp   
   >>>>>   
   >>>>> It seems to be the only way of doing this without branches, flags or   
   >>>>> other expensive nonsense. But, as ever, there may be a better way. Any   
   >>>>> suggestions?   
   >>>>   
   >>>> I don't think the above solution will work.  If I read it correctly   
   >>>> (as it appears to be mixing ISAs), you'll lose your relative stack   
   >>>> pointer position with the AND, and since it's an unknown (it will   
   >>>> either change the value of rsp or not), then it won't be reliable.   
   >>>   
   >>> It does. Either the AND doesn't change RSP and we pop the second copy,   
   >>> or it does and we pop the first.   
   >>>   
   >>> If I'm passing parameters beyond 4, then that needs parameters pushed on   
   >>> the stack. An even number can use AND SPL $F0 and an odd number OR SPL   
   >>> $08 as in   
   >>>   
   >>>        push   rsp   
   >>>        push   [rsp]   
   >>>        and    spl $F0    ; align to 16   
   >>>        push   r14        ; two extra parameters = 16   
   >>>        push   r15   
   >>>        call   funkychicken   
   >>>        add    rsp $8   
   >>>        pop    rsp   
   >>>   
   >>> or   
   >>>   
   >>>        push   rsp   
   >>>        push   [rsp]   
   >>>        or     spl $08   ; align to 8 byte   
   >>>        push   r15       ; one extra parameter   
   >>>        call   funkychicken   
   >>>        add    rsp $4   
   >>>        pop    rsp   
   >>   
   >> #1 -- That will change the value of the stack pointer, but you   
   >>        don't know if it changed or not.  If it was already aligned,   
   >>        it would've done nothing, but if it wasn't aligned, it   
   >>        would've adjusted it.  And when you return, you'll be at a   
   >>        point of not knowing whether or not it should be adjusted.   
   >>        Your subsequent pop rsp will be off by 8 bytes potentially.   
   >   
   > That's why there are two identical values on the stack provided by the   
   > pushes of RSP and [RSP] (which is RSP at the point of the first push).   
      
   You alter rsp after that push, so the value you'll be popping back   
   will either be correct (it was already aligned) or wrong, it was not   
   aligned and needed the bits lopped off, which now has rsp pointing   
   to some new value when you finally execute your pop rsp.   
      
   >> #2 -- What is "spl"?   
   >   
   > The low order byte of RSP.   
      
   I haven't seen that before.   
      
    > It's key to understanding why it works. Anyhow, I'm looking for an   
    > alternative, and might use the register version.   
      
   I still don't think your version will work reliably.   
      
   Thank you,   
   Rick C. Hodgin   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca