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]

Re: Coroutines


On 6/16/06, Dustin Laurence <dustin@laurences.net> wrote:
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.
...
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).

Wow. How many is that in kyu?


As the quicksand closes in above our heads I'll try to answer:

I don't have any GCC credibility either but I once got an approving off-list
reply from Damian Conway while discussing coroutines in the context of
Perl 6 features -- which had me reading the university library's dusty
copy of Knuth's Art of Computer Programming -- so I have done a little
homework in this problem domain, although my ideas about GCC internals
are rough and possibly naive and/or incorrect.

That said, my thoughts on the question of how to implement coroutines
using the GCC system are that it would best be done by abandoning the
idea of using the "native" stack for your program's "logical" stack.  Your
target language has some concept of multiple stacks, and recursion, so
you will have to implement these stacks some how, unlike TAOCP's
coroutines that manipulated global variables in a stackless environment.

Why not implement your stacks as linked lists of dynamically allocated
stack frame objects, and coerce your language into primitives that
operate on those objects instead of trying to force things to be C-like?

This apprach might not make sense -- I am sure if I search the
archives I will find out why, for instance, GNU Lisp is a separate
project from GCC instead of merging.

GCC might not be the best back end for your project.
At some point someone asked the perl 6 people why they were designing
Parrot when the scheme48 internals were available -- here is scheme48's
documentation on threading
http://s48.org/1.3/manual/manual-Z-H-8.html#node_chap_6
and the answer was "because nobody knew about it"

So the other thought, or the rest of the thought, is, why try to force
your language into GCC when it might be easier to force it into something else?

--
David L Nicol
"you couldn't bullshit [Bill Gates] for a minute
because he was a programmer. A real, actual,
programmer." -- Joel Spolsky


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]