mirror of
git://git.code.sf.net/p/sbcl/sbcl
synced 2026-09-10 07:26:40 -04:00
8351107b85
* Declare ENTER-ALIEN-CALLBACK as unsafe. * Instead of trying to share the Lisp from alien type parsing code for all callbacks with the same type signature, just inline the wrapper code directly into the body of the Lisp function. This simplifies how callbacks are handled and allows us to remove the Lisp trampoline layer as well, thereby reducing some call indirection overhead. Another benefit is that the declared types of the arguments are available to the compiler now that the type parsing code and the actual function body are in the same function, allowing the compiler to use unboxed arithmetic for addition when the arguments are both declared sb-alien:INT for example. * We dispose of the ALIEN-CALLBACK macro which associates a callback entry point directly to an existing Lisp function. This functionality was not exported and people don't seem to use callbacks in this way. If the user wants a Lisp function that is associated with multiple differently typed callbacks, the user can do so manually by declaring a separate Lisp function and defining multiple alien callables calling it. It is better to allow the user the option of using unboxed arithmetic than to default to allowing differently typed callbacks for the same function. * The desire to share these Lisp wrappers may have been due to space concerns, but generally speaking other kinds of argument and result coercion code is typically inlined and furthermore the type parsing code resides in GC-managed space, so it's okay that the code now exists per alien callable instead of per type signature. It's actually more of a concern that assembler wrappers are allocated per alien callable in uncollected static space. * A micro-benchmark with an alien-funcall of a callback that adds two numbers shows a 5-10% improvement in speed, presumably due to losing a layer of indirection. * Update the internals manual entry accordingly, noting in passing how foreign threads are handled specially. |
||
|---|---|---|
| .. | ||
| 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>.