[slime-devel] SLIME CMUCL restart-frame

[Helmut Eller]

Lynn Quam <quam at ai.sri.com> writes:

> Is there any chance that SLIME:RESTART-FRAME will be implemented for
> CMUCL?  I guess I do not know the limitations of the CMUCL stack
> frames and whether this is possible.

I think this would be quite a bit of work.  Some random thought about
the topic:

To restart the frame, we have to restore the dynamic environment for
that frame.  This is IMO the main problem.  The dynamic environment
consists basically of all the stack pointers (control stack, binding
stack, alien/number stack, eval stack), current catch block, and
current unwind-protect block.  AFAIK, it is currently only possible to
determine the control stack pointer, catch block and unwind-protect
block.  The other information is "there" in some way, because it is
needed to implement THROW, but unfortunately, it is not easy
accessible.

One way to make it accessible, would be to add some bits to the
debug-info.  E.g., we could record how many special bindings/alien
slots a frame has and use that to compute the binding stack pointer in
the calling frame.

A simpler, but less efficient, possibility would be to insert CATCH
forms for those frames that should be restartable.  CMUCL saves the
dynamic environment at each CATCH and to restore dynamic environment,
we could then just throw to that tag.  Saving and restoring all those
stack pointers is probably a bit expensive and so this whole approach
has only limited utility.  SBCL does something like this for (debug 3).

Yet another idea, would be to introduce a special kind of frame for
dynamic bindings, catch, unwind-protect, with-alien etc.  Adding the
extra debug-info to those frames would then be relatively easy.  I
think Lispworks does something like this.

The next problem are the assembler routines to actually unwind the
stacks, execute unwind-protect blocks, undo special bindings etc.
This is probably not very difficult, because it is already done by
THROW, but it is platform dependent.

Another (minor) problem are the arguments for the frame, because
arguments are often no longer available.  It is probably good enough
to ask the user in this case.

Interesting stuff, but I doubt that it's worth to bother.

Helmut.