On Sat, Nov 13, 2010 at 2:30 PM, John Cowan <co...@mercury.ccil.org> wrote: > John Tobey scripsit: > >> I am imagining a calling convention, usable in C via >> __attribute__((...)), that does not preserve the caller's stack >> pointer. > > Normally, what is preserved is the frame pointer and the return address. > You can suppress the frame pointer in gcc using the option > -fomit-frame-pointer, > at the expense of debuggability. I don't know any way to turn off retaining > the return address.
Yes, the various calling conventions for x86 (cdecl, stdcall, fastcall, etc.) all require called functions to preserve the frame pointer and a few other registers. What the function does with these registers while it executes does not matter to the calling convention, though a frequent use is to help debuggers. (There are other ways now of providing the same information to GDB.) What concerns the calling convention is that the registers hold the same value on return as on entry. I have designed a new convention, which I imagine someday seeing GCC support. I have tested it using Assembly. It specifies the same callee-save registers as the other conventions, *except* that the others all require the stack pointer on return to have some relationship (such as equality) to its value on entry. The new convention (call it "funcc", pronounced "funxy") merely requires SP, on return, to point to a valid stack, in no particular relationship to the caller's frame. It's as if every FuncC function might, but does not have to, behave like alloca(). Of course, one must detect or handle stack overflow somehow. GCC already can insert stack checks and probes, if I read the docs correctly. My prototype uses a guard page, special requirements of the frame pointer, and a SIGSEGV handler that fixes up the overflowing thread. A FuncC compiler wouldn't have to "turn off retaining the return address", though my prototype uses a register for it rather than a stack slot. The C return address would play its traditional role, taking the place of the continuation parameter in Chicken. I believe that this minor change to the standard calling conventions, plus some library support for memory management, can provide C (and lots of languages) with cheap, full continuations, closures, and native thread support. I'm sharing this with the list just because I suspect a few brains here think like mine. If this project advances, I will soon dive into the GCC world. Cheers, John _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
