This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
I'm pretty sure this is stepping into deep quicksand, but I'll ask anyway...I'm interested in writing an FE for a language that has stackable coroutines (Lua-style, where you can yield and resume arbitrarily far down the call stack). I'm trying to wrap my head around what would be involve and how awful it would be. There are a few "coroutines in C" packages packages laying around, but they don't seem to be stackable (I'm sure the ones based on Duff's device aren't). Since you can't switch call stacks from C I think what I want is impossible at that level. So I'd appreciate any comments or info on the following possibilities, or any others I didn't think of: 1. Build with pthreads. This has to be doable and even straightforward, but it seems like full threading machinery is very heavyweight for this. Most coroutines are conceptually a strictly user-space control structure and would be much faster implemented that way. Also, that would make the FE depend on pthreads, which I bet is undesirable. 2. Build with a purely user-space threads package. This ought to eliminate a bunch of locking and context switching overhead, so it seems like a plausible idea. But it may still be too general and in any case it has the disadvantage of importing the package into GCC itself when I get to building the FE. 3. Non-portable library. Perhaps yield() and friends can be made to work with a bit of in-line assembly to set and restore the stack pointer and registers to/from a chunk of heap (obtained with malloc or mmap I guess, if you can get the right access bits). This seems plausible, but it has the disadvantage of requiring an implementation for every architecture. Nasty for a GCC FE if avoidable, unless it made it into glibc (seems unlikely). (For a few seconds it seems like longjmp() hackery would be sufficient, but you oughtn't think about jumping back down the stack with longjmp() and you still haven't answered the question of how you're going to allow the caller to call other functions and coroutines in between resume() calls.) 4. GCC extension. Perhaps there is a way to do this in RTL, I just don't know nearly enough to say. If so, then the non-portable code is confined to things that already have to be maintained. It also would allow fully stackable C coroutines as a GCC extension, though I don't know if anyone but me would care about such a thing. Perhaps the absence of such an extension is a subtle hint of how deep that quicksand is. :-) OTOH if it is possible I'd consider trying to write it, if my GCC-fu ever reaches the requisite level (my rank is somewhere below "pale piece of pigs ear" right now). Any enlightenment is most welcome, even if only to tell me what a stupid idea it is. :-) Dustin
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |