From: invalid@invalid.invalid   
      
   Pancho  writes:   
   > On 2/5/26 16:03, Richard Kettlewell wrote:   
   >> Pancho  writes:   
   >>> On 2/5/26 14:14, The Natural Philosopher wrote:   
   >>>> The first is of course implementation specific. C can specify a data   
   >>>> stack separate from a program stack and avoid code corruption,   
   >>>> leaving only data corruption...   
   >>>   
   >>> Can it?  Naively, I would have thought C was normally built on top of   
   >>> native assembler function calls, which dictates a shared stack.   
   >>> Obviously you could implement a function call independent of   
   >>> assembler, but does anyone, in practice?   
   >>   
   >> You’d leave the call stack as it is (i.e. CALL and RET, on x86) and   
   >> use another register to manage the data stack (maybe rbp on   
   >> x86). I’ve never heard of anyone doing it for C but I don’t think   
   >> there’s any fundamental obsctacle to it. It’d be a distinct ABI, so   
   >> not particularly convenient to integrate into existing systems.   
   >   
   > I was assuming the hardware stack was more than just a register, and   
   > memory. i.e. I assumed there were specific pop/push instructions which   
   > were optimised to get data and adjust a register stack pointer as a   
   > single instruction. So there would be a performance hit in a software   
   > stack where multiple instructions would be needed.   
      
   The call stack _does_ have specialized instructions: CALL and RET on   
   x86. If you wanted to build your own call stack, replacing CALL would   
   mean:   
   - get return address into a register   
   - decrement call stack pointer   
   - store it to your call stack   
   - jump to call target   
      
   Four instructions instead of one, with dependencies on the first two.   
   Emulating RET would take three instructions.   
      
   For the data stack the situation is different. On x86 PUSH and POP   
   exist, but even with the regular stack you don’t have to use them: you   
   can adjust the stack pointer by the maximum amount needed on entry and   
   exit and then use normal load/store instructions with relative   
   addressing modes. That works just as well with any register. Compilers   
   generally mix this strategy with PUSHes and POPs to some degree.   
      
   As an example, https://godbolt.org/z/ac1rj9aGe:   
   - PUSH/POP are used to preserve callee-saved registers (L2-5 and L31-34)   
   - it directly modifies ESP to create/discard a stack frame (L6, L30)   
   - it uses ESP-relative indirect addressing to store/retrieve d (L19,   
     L26)   
   - it also uses ESP-relative addressing to set the argument to report   
     (L23, L28), rather than using PUSH, perhaps because it removes the   
     need for a POP after the call.   
      
   The above is quite x86-centric.   
      
   - Some architectures have pre-increment and post-decrement address   
     modes, in which case the emulated CALL/RET are each one instruction   
     shorter and there are no special PUSH/POP instructions. Essentially   
     you can use any register (or at least, any address register) as a   
     stack pointer, although there is usually a platform convention about   
     which you choose.   
      
   - Some architectures use a link register for the most recent return   
     address, meaning that calls to ‘leaf’ functions don’t touch call stack   
     memory at all.   
      
   --   
   https://www.greenend.org.uk/rjk/   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)