chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Re: Other Cheney-MTA systems?


From: Alan Post
Subject: Re: [Chicken-users] Re: Other Cheney-MTA systems?
Date: Sat, 13 Nov 2010 17:49:37 -0700

I only have "sounds very interesting" to add to the discussion, but
if for some reason encouragement was the cause of your not making
forward progress, please feel free to continue working now.  :-)

I would be happy to hear how this work goes as you hit milestones.

-Alan

On Sat, Nov 13, 2010 at 04:56:18PM -0500, John Tobey wrote:
> On Sat, Nov 13, 2010 at 2:30 PM, John Cowan <address@hidden> 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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/chicken-users

-- 
.i ko djuno fi le do sevzi



reply via email to

[Prev in Thread] Current Thread [Next in Thread]