From: Pancho.Jones@protonmail.com   
      
   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.   
      
   Looking at Google, it appears my simplistic view of pushing arguments   
   onto the stack is wrong anyway. There seems to be optimisations   
   involving using registers for the first few arguments (x86/64), more so   
   with RISK_V, only using the stack when necessary. I guess there are also   
   parallel instructions to push multiple registers onto a hardware stack   
   in one go.   
      
   But I take your point about the protection of execute permission on   
   memory areas etc.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)