search for: destroy_block

...(may not always be needed, since we're keeping never de-allocating old blocks). 2. Copies everything addressed SP relative to the new block. Adjusts the stack pointer. 3. Saves the real return address in the block header. Modifies the return address on the stack to point to a cleanup routine, destroy_block. 4. "Returns" to the original function prologue. Since we can't really use the stack to communicate the return address, one of the callee-clobbered registers will be used. The destroy_block stub restores the stack pointer and the instruction pointer from the current block header. Si...

...L. If it is NULL, it will allocate a new block and save it to saved_stack. It if isn't, it'll simply restore saved_sp, saved_ip. 2. In case a new block was allocated, it will pretty much do what setup_block does, after which it will adjust the SP to make space for the saved registers. The destroy_block procedure will also have to be a little different (mentioned below). There are four things (relevant to this discussion) a co-routine can do: Yield This returns control to the calling function, without forgetting the current state of the function. To do this, we save saved_ip and saved_sp. Every...

...e a new block and save it to saved_stack. It if isn't, it'll > simply restore saved_sp, saved_ip. > > 2. In case a new block was allocated, it will pretty much do what > setup_block does, after which it will adjust the SP to make space for > the saved registers. > > The destroy_block procedure will also have to be a little different > (mentioned below). > > There are four things (relevant to this discussion) a co-routine can do: > > Yield > > This returns control to the calling function, without forgetting the > current state of the function. To do this,...

...saved_stack. It if isn't, it'll >> simply restore saved_sp, saved_ip. >> >> 2. In case a new block was allocated, it will pretty much do what >> setup_block does, after which it will adjust the SP to make space for >> the saved registers. >> >> The destroy_block procedure will also have to be a little different >> (mentioned below). >> >> There are four things (relevant to this discussion) a co-routine can do: >> >> Yield >> >> This returns control to the calling function, without forgetting the >> current st...

...t, it'll >>> simply restore saved_sp, saved_ip. >>> >>> 2. In case a new block was allocated, it will pretty much do what >>> setup_block does, after which it will adjust the SP to make space for >>> the saved registers. >>> >>> The destroy_block procedure will also have to be a little different >>> (mentioned below). >>> >>> There are four things (relevant to this discussion) a co-routine can do: >>> >>> Yield >>> >>> This returns control to the calling function, without forget...

On Sun, Apr 10, 2011 at 4:16 PM, Chris Lattner <clattner at apple.com> wrote: > > On Apr 10, 2011, at 2:45 PM, Talin wrote: > > I wonder - would something like this allow for multiple stacks for a single > thread? I'm thinking of something like continuations / fibers / green > threads, which would be very handy. > > > I haven't looked at the proposal, but

On Apr 10, 2011, at 2:45 PM, Talin wrote: > I wonder - would something like this allow for multiple stacks for a single thread? I'm thinking of something like continuations / fibers / green threads, which would be very handy. I haven't looked at the proposal, but yes, this would be very useful functionality for LLVM to provide. -Chris > > On Wed, Mar 23, 2011 at 3:07 AM,