search for: setup_new_block

...or the ones which don't, we can assume some worst-case upper bound. Since the block size is a constant power of two, this can be done using a bitwise and and an integer comparison. If there isn't enough space in the current block, the control jmps (does not call) to a naked function (called setup_new_block) *** setup_new_block: setup_new_block will be small naked function emitted into all programs being compiled with segmented stacks. It does the following: 1. Checks if the current block's next pointer is populated or not. 2. In case it isn't (i.e. is NULL), it allocates a new block, sets...

On Wed, Mar 23, 2011 at 03:37:02PM +0530, Sanjoy Das wrote: > I intend to start with the simplest possible approach - representing the > stack as a doubly linked list of _block_s, the size of each _block_ > being a power of two. This can later be modified to improve performance > and accommodate other factors. Blocks will be chained together into a > doubly linked list structure

...e. This will be the first block in the chain of blocks to follow. The structure of the block will be similar to the structure of a regular stack block, except that it will also have space to store two registers - this_ip and this_sp. The prologue of a co-routine will jump to a function similar to setup_new_block (setup_new_block_coroutine) which will work like setup_new_block, except: 1. It will first check if saved_stack is NULL. 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 w...

Hi All! I will be applying to the LLVM project for this GSoC, and I wanted some preliminary sanity check on my project idea. I intend to implement split (segmented) stacks for LLVM (like we have in Go, and as being implemented for GCC [1]). A lot of what follows is lifted from [1]; I will progressively add more details as I get more familiar with the LLVM codebase. I intend to start with

...n the chain of blocks to follow. > > The structure of the block will be similar to the structure of a regular > stack block, except that it will also have space to store two registers > - this_ip and this_sp. > > The prologue of a co-routine will jump to a function similar to > setup_new_block (setup_new_block_coroutine) which will work like > setup_new_block, except: > > 1. It will first check if saved_stack is NULL. 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 cas...

...low. >> >> The structure of the block will be similar to the structure of a regular >> stack block, except that it will also have space to store two registers >> - this_ip and this_sp. >> >> The prologue of a co-routine will jump to a function similar to >> setup_new_block (setup_new_block_coroutine) which will work like >> setup_new_block, except: >> >> 1. It will first check if saved_stack is NULL. 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....

...t; The structure of the block will be similar to the structure of a regular >>> stack block, except that it will also have space to store two registers >>> - this_ip and this_sp. >>> >>> The prologue of a co-routine will jump to a function similar to >>> setup_new_block (setup_new_block_coroutine) which will work like >>> setup_new_block, except: >>> >>> 1. It will first check if saved_stack is NULL. If it is NULL, it will >>> allocate a new block and save it to saved_stack. It if isn't, it'll >>> simply restore...

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,