On Fri, 31 Jul 1998 05:07:14 +1000, Warner Losh <impat_private> wrote: >In message <98Jul30.074943est.40326at_private> Peter Jeremy writes: >: I wonder how feasible it would be to modify GCC to generate code with two >: stacks (or something equivalent): one for local variables, the other for >: parameters and return addresses. As a point of clarification, that was actually written by "John D. Hardin" <jhardinat_private>. >Foreach function on function entry save the return location and bump a >pointer. This is effectively a second stack. However, no additional >support is needed from the kernel, Something needs to manage what happens when this array of saved return addresses (__global_return_ptr in the sample code) fills up. The sample code has no checks for this. Under a typical Un*x OS, you just keep pushing data onto the stack. When you reach the end of the allocated stack, the process gets a page fault (or similar). The kernel allocates another page of memory for the stack and the process continues obliviously. This sort of functionality needs to be provided for any `second stack' approach - either within the kernel, or using a SIGSEGV (or similar) handler. >Having kernel support for two stacks (esp for code, ebp for data) >would be interesting, but the code generation might be impacted more, >since ebp is generally referenced with both + and - args for locals >and parameters respectively. I don't think so. From some back-of-envelope scribbles, the changes are fairly trivial. The compiler just needs to build a local variable frame based on the old frame pointer instead of the spack pointer. If the parameters are passed on the same stack as local variables, the function calling code needs to push parameters via the frame pointer instead of the stack pointer. Peter -- Peter Jeremy (VK2PJ) peter.jeremyat_private Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:11:13 PDT