I'm looking at the very same problem, hoping to get very lightweight
user-level threads for use in discrete event simulation.
It would be very nice if it was possible to write an inlined piece of
assembler that saved the program counter and the stack pointer and
then be able to say to GCC that everything is clobbered by those few
lines of assembler.
Ideally this clobber should include all registers, including callee-
saved registers, otherwise you need to explicitly save at least
those. With that "über"-clobber I think it would be possible to
implement very cheap context switches, where only the registers that
GCC knows are required when resuming the context are actually saved.
All attempts to say clobber-all that I've made result in problems,
typically failure to reload.
Is there a safe way to say to GCC that everything is clobbered in a
way that is safe across all possible optimization settings?
I'm particularly interested in the x86_64 target.
On a side note, when writing this type of context-switching code one
would often need to insert (local) labels in the assembler to serve
as target for thread resumption. GCC is very aggressive in removing
labels which according to C/C++ semantics he can prove are never
reached. It would be nice to have an attribute to say "please, GCC,
for reasons I cannot explain to you, this label will actually be
reached eventually".
This is particularly useful combined with the "über"-clobber of
above, otherwise GCC could easily convince himself that not too much
needs to be saved.
-- Maurizio
On Jun 17, 2006, at 5:28 AM, Gabriel Dos Reis wrote:
Andrew Haley <[EMAIL PROTECTED]> writes:
| Dustin Laurence writes:
| > On Fri, Jun 16, 2006 at 02:05:13PM -0700, Mike Stump wrote:
| >
| > > If every language were going to have the feature, then,
moving it
| > > down into the mid-end or back-end might make sense, but I
don't think
| > > it does in this case.
| >
| > Personally, I'd like, and use, decent coroutines in C. But
perhaps I am
| > the only one.
| >
| > > I wouldn't start with pthreads I don't think.
| >
| > That was my thought--I played with it some but I intended it
as a bit of
| > threads practice. Using threads to emulate a synchronous
construct just
| > seems *wrong.*
|
| You need a way to switch from one stack to another, but why not
leave
| open the possibility of implementing this in a number of different
| ways?
Yup.
| You need detach() and resume() [in Simula notation] and these
| can be provided either by low-level stack-switching or by invoking a
| pthreads library.
I wouldn't use a thread library because many uses of coroutine are to
implement low-cost, efficient, alternatives to thread where, for
example,
the full power of threads are not essential.
-- Gaby
