Perhaps setjump etc. isn't necessary.  Why not have the primitive make a
call that leaves what looks like an ordinary call-frame on Smalltalks stack
waiting for a return with a the PC counter hacked backwards so that it
RERUNS THE PRIMITIVE.  You an have two primitives if that makes it easier.

If you want collectable variables, perhaps you can stick these primitives
inside of a block or method with local variables and let them primitive
access ordinary Smalltalk locals.

[ aBlockToLoop | aLocalForPrimitive | <primitive 500> "saves interpreter
state and initializes the loop" <primitive 501> "invokes aBlockToLoop with a
hacked stack to rerun itself - uses aLocalForPrimitive to store a
collectable variable" ] value: ...

----- Original Message ----- 
From: "Andreas Raab" <andreas.raab at gmx.de>
To: "Joshua Scholar" <jscholar at access4less.net>; "The general-purpose Squeak
developers list" <squeak-dev at lists.squeakfoundation.org>; "John M McIntosh"
<johnmci at smalltalkconsulting.com>
Sent: Wednesday, December 01, 2004 2:52 PM
Subject: Re: Adding loop primitives/optimizations (was
MakingSet/Dictionaryetc. loops more robust)


> Joshua,
>
> The real restriction is that primitives are *always* leafs. They never
call
> back into the interpreter and even if they could (there are some really
ugly
> attempts to make this work) there isn't a way to "return to a primitive
> invokation". That's the one that really kills you. Squeak doesn't run off
> the C stack meaning that neither a Squeak method invokation nor a method
> return have anything in common with a C function call or return. You could
> hack this via setjmp and longjmp and friends but that is likely slower
than
> running Squeak bytecodes instead. Even if you did this you'd still have to
> deal with -say- the debugger and a whole lot of other "interesting"
issues.
>
> Cheers,
>   - Andreas
>
> ----- Original Message ----- 
> From: "Joshua Scholar" <jscholar at access4less.net>
> To: "John M McIntosh" <johnmci at smalltalkconsulting.com>; "The
> general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Wednesday, December 01, 2004 11:32 PM
> Subject: Re: Adding loop primitives/optimizations (was
> MakingSet/Dictionaryetc. loops more robust)
>
>
> >I really should leave now, but I just wanted to point out that you
> > misunderstood what Tim Rowledge and I were talking about.
> >
> > The problem here is an _primitive_ iterator over a _block of regular
> > Smalltalk code_.  In this case, the plug-in has to call back into the
> > interpreter (I hope there's a way to do that).
> >
> > What I was saying is that in this case, Slang/C code needs variables
that
> > count toward not collecting an object, because inside the plugin's code,
> > the
> > interpreter is running in all it's glory.
> >
> > And you know what, it's not onerous at all for objects to be relocated,
as
> > long as the GC updates the registered Slang variables just like it
updates
> > the rest of the variables in the system.
> >
> > Ok, I can see that if you didn't design this sort of flexibility into
the
> > the VM then adding it could be a real job, but you know, it's a heavy
> > restriction of Slang if this isn't possible.  Another way of looking at
> > it,
> > mya be that these are primitives that should be integrated into the
> > interpreter the way current invocation block code is, not considered a
> > plug
> > in as such.
> >
> > Joshua Scholar
> >
> >
>