search for: splitstack

I'm trying to implement something similar to this: http://gcc.gnu.org/wiki/SplitStacks in LLVM. The reason I want this is so that I can have dynamically growing and shrinking stacks in my programming language. In order to do this, I need to be able to check for overflow of a stack frame. The methods of doing this are outlined in the link above, but my intention is to pass the cur...

...lowed to overflow to another datatype. > > If they aren't, in fact, on separate memory segments, are you aware of a way to > place a non-readable/-writable segment in between two other stack segments? it is essentially the same thing as GCC's split stacks: http://gcc.gnu.org/wiki/SplitStacks Ciao, Duncan. > > Thanks, > > ~Brent Roth~ > > On Mon, Jun 3, 2013 at 3:20 AM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > Hi Brent, LLVM supports segmented stacks, I suggest you do a case > insensitive grep for s...

Hi Duncan, Are the segmented stacks actually on separate memory segments? My intended purpose for placing different datatypes on separate stacks is such that memory accesses to one datatype won't be allowed to overflow to another datatype. If they aren't, in fact, on separate memory segments, are you aware of a way to place a non-readable/-writable segment in between two other stack

...they aren't, in fact, on separate memory segments, are you aware of a >> way to >> place a non-readable/-writable segment in between two other stack >> segments? >> > > it is essentially the same thing as GCC's split stacks: > > http://gcc.gnu.org/wiki/**SplitStacks<http://gcc.gnu.org/wiki/SplitStacks> > > Ciao, Duncan. > > >> Thanks, >> >> ~Brent Roth~ >> >> On Mon, Jun 3, 2013 at 3:20 AM, Duncan Sands <baldrick at free.fr >> <mailto:baldrick at free.fr>> wrote: >> >> Hi Brent,...

On Wed, Apr 7, 2010 at 12:43 PM, Arlen Cox <arlencox at gmail.com> wrote: > I'm trying to implement something similar to this: > http://gcc.gnu.org/wiki/SplitStacks in LLVM.  The reason I want this > is so that I can have dynamically growing and shrinking stacks in my > programming language.  In order to do this, I need to be able to check > for overflow of a stack frame.  The methods of doing this are outlined > in the link above, but my intentio...

...in this > block's header. > > One thing I'd really like some input on is whether implementing split > stacks would be useful enough to warrant the effort (especially keeping > in mind that this is pretty useless on 64 bit architectures). > > [1] http://gcc.gnu.org/wiki/SplitStacks > -- > Sanjoy Das > http://playingwithpointers.com > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- -- Talin --------------...

...ing up the stack pointer saved in this block's header. One thing I'd really like some input on is whether implementing split stacks would be useful enough to warrant the effort (especially keeping in mind that this is pretty useless on 64 bit architectures). [1] http://gcc.gnu.org/wiki/SplitStacks -- Sanjoy Das http://playingwithpointers.com

...another datatype. > > If they aren't, in fact, on separate memory segments, are you aware of a way to > place a non-readable/-writable segment in between two other stack segments? > > it is essentially the same thing as GCC's split stacks: > > http://gcc.gnu.org/wiki/SplitStacks > > Ciao, Duncan. > > > Thanks, > > ~Brent Roth~ > > On Mon, Jun 3, 2013 at 3:20 AM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > Hi Brent, LLVM supports segmented stacks, I suggest you do a case > ins...

...n this > block's header. > > One thing I'd really like some input on is whether implementing split > stacks would be useful enough to warrant the effort (especially keeping > in mind that this is pretty useless on 64 bit architectures). > > [1] http://gcc.gnu.org/wiki/SplitStacks > -- > Sanjoy Das > http://playingwithpointers.com > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > -- T...

Having read through Stackless Python's web pages a bit: 1. They're doing pretty much what I'd like to do, except that I don't want to be tied to a particular language and I'd like to be able to use the stack. (Also, stack use is inescapable with LLVM, as far as I can tell). 2. We should be able to support "hard switching" in Stackless Python by adding a

...s header. >> >> One thing I'd really like some input on is whether implementing split >> stacks would be useful enough to warrant the effort (especially keeping >> in mind that this is pretty useless on 64 bit architectures). >> >> [1] http://gcc.gnu.org/wiki/SplitStacks >> -- >> Sanjoy Das >> http://playingwithpointers.com >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>...

On the other hand, stack manipulation really ought to be handled by the target, since only the target knows the details of how the stack is laid out to begin with. Also, if we have stack manipulation calls in the IR, optimization quickly becomes very difficult. Unless we just allow optimizers to ignore the stack manipulations and assume they're doing the "right" thing. On the

...into object files compiled with segmented stacks. The linker will then use as a flag. This is exactly the approach mentioned in [1]. However, this approach is suboptimal, and to get full benefits of segmented stacks, all code needs to be compiled with segmented stacks. [1] http://gcc.gnu.org/wiki/SplitStacks -- Sanjoy Das http://playingwithpointers.com

..., since the native code has not been generated yet. This is exactly the approach mentioned in [2]. However, this approach is suboptimal, and to get full benefits of segmented stacks, all code needs to be compiled with segmented stacks. [1] http://pastebin.com/UDuADcMC [2] http://gcc.gnu.org/wiki/SplitStacks -- Sanjoy Das http://playingwithpointers.com

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

...with a pass that > forces recursive calls to spawn a new context and turns large alloca's > into malloc's, making it safer to have a bunch of little stacks > without any needed juggling. This sounds like a stopgap until real split stacks can be implemented. http://gcc.gnu.org/wiki/SplitStacks#Backward_compatibility describes some of the other difficulties in getting even this much to work. (foreign calls, and function pointers, at least)

...forces recursive calls to spawn a new context and turns large alloca's >> into malloc's, making it safer to have a bunch of little stacks >> without any needed juggling. > > This sounds like a stopgap until real split stacks can be implemented. > http://gcc.gnu.org/wiki/SplitStacks#Backward_compatibility describes > some of the other difficulties in getting even this much to work. > (foreign calls, and function pointers, at least) > True. Some front-ends have more control over this than others, though. And users of a C-like front end would find this pass helpful...