search for: explicitlymanagedstackframes

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

...frames". Does anyone know what techniques this > cryptic statement might be referring to? > > Thanks! > I would say it means to have a "stackless" code generator. You may want to see http://en.wikipedia.org/wiki/Spaghetti_stack and http://www.nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt . "Stackless" means that you do not use the "system" stack, but that rather, your language frontend manages the stack frames itself. Hope this is any help, Jonathan

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! -- William <wmorgan-llvm at masanjin.net>

Hi, going through the tutorial (http://llvm.org/docs/tutorial/LangImpl8.html) it linked to a post from 2004 (http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt) stating that LLVM does not allow explicit stack management. It also mentioned that this was a deficiency in LLVM, leading me to think that there is a possibility that things have changed since them. I'm not just looking to implement garbage collection that may have been done already...

> [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

...able to perform, add > > the ability to specify the ordering of local variables in the stack If you need specific locations for everything you're allocating on the stack, you should probably just use a continuation-passing style like the one mentioned in http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt ; LLVM won't preserve the values of variables allocated with alloca whose address isn't taken. -Eli

...calls another tasklet function, then at the LLVM level the function will be split into a couple functions (with further split happening if there are more tasklet function calls later on) where the function will become a tail-call. At this point, refer to the link http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt that I am using as a basis, although with some minor changes in passed around data. First difference, I am not using a garbage collector (not at this moment anyway, and the design of the language may not require that I need one at all actually, most things will be on the fake tasklet stack, wh...

To the list of modifications I need to be able to perform, add the ability to specify the ordering of local variables in the stack the ability to have one thread access the contents of another thread's stack. There may be more I am forgetting, so simply put I need to be able to have complete control over the stack. It's layout, its contents etc.

...; > the ability to specify the ordering of local variables in the stack > > If you need specific locations for everything you're allocating on the > stack, you should probably just use a continuation-passing style like > the one mentioned in > http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt ; > LLVM won't preserve the values of variables allocated with alloca > whose address isn't taken. > > -Eli > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs...

Hi everybody, I'd like to try implementing a pass that transforms all functions (and function calls, returns, etc.) to CPS, so that TCO can get rid of all (or most of) the function calling overhead (because, as you probably know, the side effect of using CPS is that all function calls become tail calls). That being said, and since I'm pretty new to LLVM, I'd like to ask a couple

...ly talked about it from a theoretical perspective and did a lot of hand waving on the actual specifics. Thank you for your time, Ben Chambers P.S. The document I was referring to for the notes on how to implement this in LLVM is available at this location: http://www.nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt

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, the functions check a state variable for whether or not to freeze live variables. The state var is kept p...

...the butt. > The story doesn't improve much with 3rd party coroutine libraries, > which have their own limitations (for instance, can you resume a > microthread on a different OS thread than it was created?). First, I will assume that you have read http://www.nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt and if you have not, do so. I am also working on an Actor based language. I initially started with Erlang (too difficult to bind into C++ where I have some required libraries that I need). I then went to Stackless Python (almost stupid-easy to bind with, but the switching was too slow anytim...

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

I'm losing my sanity, so I thought I'd try and generate an LLVM target for the Glasgow Haskell Compiler (GHC). In talking to some of the people in the GHC mailing list some issues have come up that I can't find a ready answer to. (Others came up that I could, so I don't feel quite as stupid or helpless as I could.) 1. Is there any way to hint that a global pointer variable