Sriram Srinivasan
2007-Jan-08 12:12 UTC
[LLVMdev] Stack switching, Active Objects and LLVM
[Apologies. This is a repost because the earlier post didn't have a subject heading and might have been missed by members] Hello, I wish to have lots of little stacks and be able to switch rapidly between them. I could do CPS transformation but don't like the overhead of creating gc'able continuation thunks and the copying from stack to heap. I'd like to explore a no-copy approach by "merely" switching a few registers, perhaps as an equivalent of the C-- "jump" instruction (as opposed to call). In other words, if a function calls "pause()", I'd like to freeze the stack and be able to resume the thread at some time, like green threads but faster (one shouldn't have to save all registers blindly). I would appreciate some pointers on what it take to do this in LLVM? The context for the question is this: I'm building a java-like language with GC & classes and message passing (no memory sharing) between active objects. I would like to be able to have several object pools that are preemptively scheduled, but within one pool, the objects are cooperatively scheduled. I'd like to have a GC to take advantage of the fact that no memory is shared. A linear type system ensures that references to objects passed in messages are owned by only one active object at any time. --sriram Thanks much.
On Mon, 8 Jan 2007, Sriram Srinivasan wrote:> I wish to have lots of little stacks and be able to switch rapidly > between them. I could do CPS transformation but don't like the overhead > of creating gc'able continuation thunks and the copying from stack to > heap.ok> I'd like to explore a no-copy approach by "merely" switching a few > registers, perhaps as an equivalent of the C-- "jump" instruction (as > opposed to call). In other words, if a function calls "pause()", I'd > like to freeze the stack and be able to resume the thread at some time, > like green threads but faster (one shouldn't have to save all registers > blindly). I would appreciate some pointers on what it take to do this in > LLVM?This sounds quite doable. There are two ways you can approach this. If you don't care about portability, you can use standard inline asm to achieve this. This works if your front-end is willing to handle knowing what to generate for each target. If you don't like this approach, you can add an llvm intrinsics, which is expanded by the code generator to the right code for the current target. -Chris -- http://nondot.org/sabre/ http://llvm.org/