mirror of
git://git.code.sf.net/p/sbcl/sbcl
synced 2026-09-10 07:26:40 -04:00
7b30deed1f
The spec says that *all* values that a dynamic-extent declared variable takes on are dynamic extent and hence can be stack allocated, not just the initial variable binding. That is, SETQ value forms should also participate in stack allocation when possible if the SETQ'd var is declared dynamic extent. Special care needs to be taken when the dynamic extent declaration is in a local function which is called by multiple local calls, since then it's not obvious where to put the cleanup code. In fact no cleanup code should be inserted at all, as function return will clean the stack. So teach the dynamic extent representation how to represent that. The work for overhauling dynamic extent representation in the IR in general and work on stack analysis is paying off now: it was basically impossible to do this in the older IR way of handling dynamic extent, but now it's fairly easy with a dedicated DYNAMIC-EXTENT node. And since stack analysis has been cleaned up with many restrictions lifted, it doesn't care about the exact dataflow related to lvars with dynamic extent and SETQs in the scope of a dynamic extent cleanup don't bother the stack-pointer-initializing walk through the graph. Also reorganize/edit/add to the manual section for dynamic extent, not only to advertise this new feature and its applications but also to make it more coherent in general (bringing it up to date at the same time). |
||
|---|---|---|
| .. | ||
| cmu-user | ||
| internals | ||
| internals-notes | ||
| manual | ||
| clean.sh | ||
| entities.inc | ||
| FOR-CMUCL-DEVELOPERS | ||
| GIT-FOR-SBCL-HACKERS.txt | ||
| GIT-WORKFLOW.md | ||
| make-doc.sh | ||
| PACKAGING-SBCL.txt | ||
| README | ||
| sbcl.1 | ||
SBCL is -- ahem! -- imperfectly documented. What can we say? Help with documentation might not be refused.:-) There is a Unix man page, sbcl.1. There is a user manual in texinfo format, in doc/manual/. (In binary distributions, the compiled-into-HTML translations are also included.) Much of the documentation for supported extensions is in their Lisp doc strings. For example, to find out how to use the SAVE-LISP-AND-DIE function in the SB-EXT package, you can execute (documentation 'sb-ext:save-lisp-and-die 'function) or (describe 'sb-ext:save-lisp-and-die) in SBCL. The user manual is incomplete, and some of its chapters are just notes that "this is similar to chapter such-and-such of the CMU CL user manual". The old CMU CL documentation can still be useful both for missing chapters of the user manual and for documentation of the internals of the system. It can be downloaded from <ftp://sbcl.sourceforge.net/pub/sbcl/cmucl-docs.tar.bz2>.