similar to: [LLVMdev] explicit stack management

William Morgan wrote: > Hi all, > > At the bottom of chapter 8 of the tutorial, on the topic of closures, > mentions that there are "often better ways to implement these features > than explicit stack frames". Does anyone know what techniques this > cryptic statement might be referring to? > > Thanks! > I would say it means to have a "stackless"

I saw this was mentioned briefly last year, but there seemed to be some confusion as to what coroutines entailed and the thread died out. This technique has an unfortunate number of names, but it does get a lot of use, including popular languages like Ruby. I'm currently working on a programming language called Minnow (http://www.minnow-lang.org). It's an actor-based language, where

On Thu, Apr 16, 2009 at 9:47 AM, Jonathan D. Turner <jonathan.d.turner at gmail.com> wrote: > I saw this was mentioned briefly last year, but there seemed to be > some confusion as to what coroutines entailed and the thread died out. >  This technique has an unfortunate number of names, but it does get a > lot of use, including popular languages like Ruby. > > I'm

Just out of curiosity, now that explicitly managed stack frames [1] are possible (given support in the code generators), is the stack register freed for other uses when the LLVM system stack isn't being used? Sandro [1] http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt

I took the liberty of forwarding this to the Stackless Python list, since they switch stacks, and I got a response at http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4467. The upshot is that they really need the ability to allocate only a tiny amount of space for each thread and grow that as the thread actually uses more stack. The way they accomplish that now is by copying the

Hi, I am using XEN-4.1.2 and linux-2.6.32 as dom0. After I upgraded stackless python from 2.5 to 2.7 (and rebuilt xen). XenAPI became unusable, I spent some time to investigate XenAPI,py, it looks fine. So, I guess xend has problem with python 2.7, because it always returned method unknown. Do I have to tweak xend to let it support python 2.7? Thanks, Eric /root # python Python 2.7.5 Stackless

On Sun, Apr 11, 2010 at 2:41 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Sun, Apr 11, 2010 at 4:09 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: >> Kenneth Uildriks <kennethuil at gmail.com> wrote: >>> As I see it, the context switching mechanism itself needs to know >>> where to point the stack register when switching.  The C

> [1] http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt Interesting. Something like this is more then sufficient for implementing by value structure passing at the llvm level :-) Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047

Right now the functionality is available, sometimes, from the C standard library. But embedded environments (often running a limited standard library) and server environments would benefit heavily from a standard way to specify context switches within a single thread in the style of makecontext/swapcontext/setcontext, and built-in support for these operations would also open the way for

I can consistently segfault the 0.10.4 gem, so I''m trying to get the subversion version working with hopes towards tracking the problem down. I have a fresh SVN checkout but: a) the version (in ferret.rb) claims to be 0.9.6; and b) Ferret::Index::FieldInfos and a couple other classes are missing at run time. It looks like this is because they''re not exported in the C

On Thu, Apr 16, 2009 at 3:21 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > > First, I will assume that you have read > http://www.nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt > and if you have not, do so. I hadn't. That's very similar to what I had tried early on, but found it was actually slower than managing my own stacks lazily (on continuation,

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

Dan, > > On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote: > >> Hi, >> >> I need to get the address of a label in jitted code. >> (This is so that I can insert a jump into the machine code to resume >> interpretation from compiled code) > > Hello, > > What's your plan for restoring register and memory state? Put everything in memory at

You can skip this first and second paragraph if you just want to get to the description, the 'real' question I want is the bottom most paragraph and may still make enough sense to read without reading everything else, but there are a few other hidden questions and opinions being asked in the rest of it. In this little scripting language I am making is basically going to be a C with Actors

I created a wiki at http://code.google.com/p/llvm-stack-switch/ Right now I just copied and formatted the document as-is... I'll go back over it with your comments in mind soon. One more question, which you can answer here or there: > Point 4 is a bit confusing. Normally, it's fine for a thread to share > some of its stack space with another thread, but your wording seems to >

On Jan 23, 2009, at 3:23 AM, Mark Shannon wrote: > Dan, > >> >> On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote: >> >>> Hi, >>> >>> I need to get the address of a label in jitted code. >>> (This is so that I can insert a jump into the machine code to resume >>> interpretation from compiled code) >> >> Hello, >>

Hi dear all, the following code is correct. but I want to use non-numeric x-axis, for example if I replace time <- seq(0,72,6) by month <- c("Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec","Pag") Ofcourse I use factor(month) instead of

OvermindDL1 wrote: > > It is using the Actor-Oriented model, not Object-Oriented. > /* snip */ > By keeping the type system based on the actual types it allows > arbitrary message passing to any other actor without needing to load > any code relating to the actors, you can just send a structure with > the appropriate ID and format and it will 'just work' as the

Hi, I am new to Ruby and Rails programming and am having difficulty with the following scenario... Consider the following model: class Studio < ActiveRecord::Base has_many :movies has_and_belongs_to_many :actors end class Movie < ActiveRecord::Base belongs_to :studio has_and_belongs_to_many :actors end class Actor < ActiveRecord::Base has_and_belongs_to_many :studios

On Sun, Apr 11, 2010 at 10:07 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > I'll forward your next draft back to the stackless folks, unless you > want to pick up the thread with them. Their reply: http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4475 Instead of @llvm.getcontextstacktop(%context), they want @llvm.getcurrentstacktop() so that they can copy