Continuation register -- last chance for objections

[Dan Sugalski]

Unless someone objects (and as this'll need some JIT re-jigging I can
see there being an issue) I'm going to add a return continuation
register to the context structure, change the invocation ops to put
the return continuation in there, and add in a RETURN keyword that
works just like a plain invoke, only it uses the return continuation
register.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Leopold Toetsch]

Dan Sugalski <d...@sidhe.org> wrote:
> Unless someone objects (and as this'll need some JIT re-jigging I can
> see there being an issue) I'm going to add a return continuation
> register to the context structure, change the invocation ops to put
> the return continuation in there, and add in a RETURN keyword that
> works just like a plain invoke, only it uses the return continuation
> register.

Needs a bit or preparation first:
- all Sub and derived structure are the same except Coroutine.
This was ages ago ok, but is now already suboptimal.
- alls callable (does "invoke") thingies should have a bit in common,
though, so that {set,get}_pointer and invoke can be inherited
- a separate C<return> opcode would be of much help for the compiler and
optimizer. It's currently a PITA to discern C<invoke Px> from C<invoke
P1> where the former can be a function return too.
If thats the RETURN keyword above, that's good.
- pcc.c needs a bit of update
- I'd like to add
ret(foo, bar)
or some then to imcc.y. This simplifies PIR syntax a lot.

and finally it needs some transition time. There's already a lot of code
around that does "invoke P1".

But these are no arguments against the change at all, I'm all for it.
Needs only some thoughts on the sequence of changes and some care to not
break too much at once.

leo