random-state.net

Nikodemus Siivola

<< next | top | previous >>

May 12th 2005 #
random, May 12th 2005

SBCL: 0.9.0 is out, which is already old news in the SBCL timescale, but probably still bears mentioning. Nothing truely humongously remarkable in sights for 0.9.1 yet — "just" plenty of bugfixes and some performance improvements.

Juho tells me he's working on XREF for SBCL, which is about as cools it gets. I'm especially excited about this as his current plan includes adding two slots (only one of which is needed for XREF) to FDEFNs (if you don't know what these are you either don't want to, or can read the sources): I'm hoping to be able to usurp the other slot for use as a debug-entry point, doing there the equivalent of:

(lambda (&rest arguments)
  (loop
    (setq arguments 
          (catch 'restart-frame 
            (return (apply original-fun arguments))))))

...giving us RESTART-FRAME for almost free, as only calls compiled at a high debug setting would use this entry point. Of course, given that this would be in FDEFN, not in the function object itself means that only named functions would be restartable. There is also some hair in here about EQness, but I think that having access to the debug-entry point only as internal compiler magic should solve that.

If it does turn out that the this will not work the way I hope it to, the next step will probably be to either instrument every high-debug call separately (which I'd really like to avoid), or instrument the callees.

Which brings me to the current single-stepper implementation of SBCL. Even though it is very neat, I'm really not all that happy with it: it bloats code hugely, fully steppable code is essentially unoptimizable, and compilation times can go through the roof.

In order to solve this I've been thinking about what kind of contract I would like to have with a stepper. I think the following would be a reasonable compromise between informativeness, steppability of normal code, and performance:

  • Code lexically enclosed with STEP is stepped fully, including most of COMMON-LISP. It makes sense to step some special operators, such as LET and GO, but not all, eg. MACROLET. This can be implemented by enhancing the current stepper a bit, but will probably be best done within an evaluator..
  • Calls to all non-inlined user-defined global functions within the dynamic contour of STEP will be stepped, including return values, irrespective of the debug level the functions were compiled with. Calls to COMMMON-LISP functions may or may not be stepped: the implementation is free to elide them. Calls to local, anonymous, and inlined functions will stepped too if the functions in questions were compiled with a sufficiently high debug level. This can be accomplished by instrumenting entries to high-debug functions and with using XREF data to add temporary wrappers around global functions called by the function we're currently stepping.

So, here's to XREF!

In other news, SBCL has gained a new commiter: Teemu Kalvas whose handiwork can be eg. seen in the UTF-8 implememtation of SBCL.