Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> ... While S registers hold pointers, they have
>> value semantics.
> Is that guaranteed? Because it probably needs to be.
It's the current implementation and tested.
>> This would restore the register contents to the first state shown above.
>> That is, not only I and N registers would be clobbered also S registers
>> are involved.
> That's correct. What's the problem? Okay, you've created an infinite
> loop, but what you're describing is absolutely the correct behaviour for
> a continuation.
Ok. It's a bit mind-twisting but OTOH it's the same as setjmp/longjmp
with all implications on CPU registers. C has the volatile keyword to
avoid clobbering of a register due to a longjmp.
>> Above code could only use P registers. Or in other words: I, N, and S
>> registers are almost[1] useless.
> No they're not. But you should expect them to be reset if you take a
> (full) continuation back to them.
The problem I have is: do we know where registers may be reset? For
example:
$I0 = 10
loop:
$P0 = shift array
dec $I0
if $I0 goto loop
What happens if the array PMC's C<shift> get overloaded and does some
fancy stuff with continuations. My gut feeling is that the loop might
suddenly turn into an infinite loop, depending on some code behind the
scenes ($I0 might be allocated into the preserved register range or not
depending on allocation pressure).
Second: if we don't have a notion that a continuation may capture and
restore a register frame, a compiler can hardly use any I,S,N registers
because some library code or external function might just restore these
registers.
> Presumably if foo() doesn't store a full continuation, the restoration
> just reuses an existing register frame and, if foo has made a full
> continuation its return does a restore by copying?
Yes, that should be a reasonable implementation.
leo
