similar to: [LLVMdev] Proposal: stack/context switching within a thread

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 routines take >> an initial stack pointer when creating the context, and keep track of >> it from

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 routines take > an initial stack pointer when creating the context, and keep track of > it from there.  If we don't actually need to interoperate with > contexts created from the C routines, we have

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

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

On Fri, Apr 16, 2010 at 9:30 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > 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

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

Sorry, I certainly didn't mean to be dishonest. I was just repeating one of the comparisons given by the research paper. Regardless, even setjmp() uses a structure of 148 bytes in size (on my machine). The main point is that with compiler support, many context switches can be easily reduced to just a few instructions and only 8 byte of memory, and even in the worst case they will outperform

Hi LLVM devs, I’d like to describe my problem, and then propose new features of LLVM which would solve it efficiently. I'm building a new statically-compiled programming language, and I plan on using LLVM as the backend. The language will have a runtime with cooperatively managed green threads (user-space "mini-threads", each with their own dynamically allocated stack). A single OS

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

I get a crash when I try to link multiple modules registered in their individual contexts. Documentation for Linker::LinkModules doesn't mention anything about contexts, and the first link succeeds. But the second link crashes. Is this not the right way to merge such modules? If not, then what is the right way? In any case, documentation for Linker::LinkModules should say if contexts are

> On 2015-Jun-01, at 11:06, Reid Kleckner <rnk at google.com> wrote: > > I'm pretty sure module linking is expected to occur in the same LLVM context. Correct. > IIRC Duncan had some proposal for how ld64 could do something clever with multiple contexts, but I've totally forgotten what it was. This was for LTO (probably unrelated to Yuri's scenario?). 1.

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

I have renamed all of the patch files to .txt, which should be acceptable for the mailer daemon at mindrot, per Angel's suggestion. I am attaching the patch files to the email, with the extra space removed and a minor correction made. Bill Parker (wp02855 at gmail dot com) -------------- next part -------------- --- port-linux.c.orig 2012-12-19 17:40:53.231529475 -0800 +++ port-linux.c

Hi, I'm Ryo Ota. I have two questions about `llvm::LLVMContext`. Q1) What is the difference between the following (A)`my_context` and (B)`global_context`? Do I have to create a LLVMContext by myself? Or use `getGlobalContext()`? Could you tell me what situation needs a LLVMContext which is created by myself such as (A)? (A) { llvm::LLVMContext my_context; // codes using only my_context (get

On Sat, Apr 10, 2010 at 12:54 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > 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

Hello All, In reviewing source code for OpenSSH-6.1p1, I found instances of deprecated library calls still within various source code files. Examples of deprecated calls are: bzero() (replaced with memset() which is ANSI compliant), index() (replaced with strchr() which is also ANSI compliant). In file 'auth2-jpake.c', I've replaced all the bzero() calls with the equivalent

https://bugzilla.netfilter.org/show_bug.cgi?id=915 Summary: segfault in error case : expr_evaluate_payload not checking payload->payload.desc being null Product: nftables Version: unspecified Platform: x86_64 OS/Version: All Status: NEW Severity: normal Priority: P5 Component: nft

Chris Lattner wrote: > Check out http://nondot.org/sabre/LLVMNotes > > %Size = getelementptr %T* null, int 1 %SizeI = cast %T* %Size to uint How incredibly cunning. :-) Thanks for that. Next stupid question. I've put together a simple coroutine/fibre style threading system on top of the Linux setcontext/getcontext stuff, which surprisingly enough seems to work *almost*

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

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>