Leopold Toetsch <[EMAIL PROTECTED]> writes: > 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.
This is, of course, why so many languages that have full continuations use reference types throughout, even for numbers. And immutable strings...
