* 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.
It was previously renamed in rev 851cbd2b but the new name was too wordy.
The motivation here is the same: some pending changes for x86-64 that make
lisp-to-lisp calls go through a linkage table (almost doing away with
all FDEFNs) is nearly ready to be committed for real now.
Anticipating that FDEFNs can be subsumed by something other than 1st-class
objects, we'll need a unified space of lisp function pointers. I tried to pick
a non-conflicting name for such space, but "linkage table" really fits.
Therefore this change renames the existing table. It was FOREIGN-LINKAGE-TABLE
in CMUCL, but "ALIEN" requires fewer keystrokes and matches DEFINE-ALIEN.
It was explicitly added in 60f84eda5c, which caused me some skepticism
as I saw no merit to keeping deceptive information in-tree. i.e. some of the
internals are not right for SBCL (and possibly not CMUCL any more) such as:
- SBCL executables don't produce three ELF files, there is no linker.sh etc.
- object.tex is more wrong than right. The widetags are completely wrong;
as are nearly all the descriptions of various headered object types.
(functions don't contain a pointer to "next function", and they don't embed
their FTYPE in the raw data portion, etc etc)
- fasl.tex is sufficiently wrong as to be of little utility - the entire point
of our LEB128-encoding is to remove bifurcation of all fops as it alludes to.
Not to mention there's no fop-uniform-vector, fop-code-format,
fop-pop-for-effect, and others.
- foreign-linkage-symbols and linkage-table-data aren't the same at all.
- our INFO database uses <category,kind> for the taxonomy, but CMUCL
named them <class,type> and said that they are compared via STRING=.
Neither is more obviously right, so this is just ridiculously confusing.
- The interpreter documentation is flat-out 100% wrong as pertains to SBCL.
All files files removed in this change are obsolete relative to SBCL, but to
revise them in-place would be worse - anyone would wonder whether they document
the current state of SBCL or CMUCL. The right fix would have been to take out
dangling links from our docs - someone can still do that! - and not to add
explictly incorrect text that increases the amount of stuff you have to
mentally weed out when doing "git grep".
Some "internals" docs are more prosasic and theoretical than detail-oriented,
so it's hard to say whether they're right or wrong. (Is it wrong to postulate
counterfactuals like "it would be nice if x,y,z held ..."?)
I didn't know what to do with Makefile, so I removed it, as well as skeletal
table-of-contents files.
So that TLS can be initialized using memset(ptr,0xff,size).
In making this change I discovered that scavenge_control_stack() was slightly
inefficient - if (is_lisp_pointer() && !from_space_p()) there is no need
to check the scavtab[] entry.
Also the text in 'objects-in-memory' was wrong- no-tls-value marker
never appears "in" a symbol's TLS field, only on the binding stack.
And all remarks about enabling those. Worst advice ever.
The comments even say they cause more problems.
("Yo dawg, I herd u like locks so I added extra locks
so you can deadlock while u deadlock")
I don't know what QSHOW_SAFE was either.
Our source code makes direct reference to some internals .tex files
found only in the CMU CL source, and even our own manual has direct
references to the CMU CL manual because the corresponding sections
haven't been written yet (for over 2 decades).
We might as well check-in the original documentation. I doubt anyone
will ever be paid to write or even finish porting such high quality
documentation, and it would be a shame to have 95% correct internals
documentation be completely missing as well.
This undoes parts of 902e9373 in the interest of following the spec by its
intent and de-facto correct interpretation versus a theoretical view
that is of little practical value.
As the test file shows, among all other implementations examined, the consensus
is 8-to-2 against treating (VECTOR NIL) as a string even where support for
(ARRAY NIL) as a type exists. And the minority stance is weak- both outliers
upgrade NIL to their widest character type in MAKE-STRING, proving beyond a
doubt that they don't really think that NIL means empty type in that usage.
So now SBCL goes along with that for maximum compatibility with everyone.
I considered a hypothetical build-time #+vector-nil-is-string feature,
but it's not worth cluttering the code for. Nobody would/should use it.
Remove a level of indirection when unbinding special bindings, instead
of saving a symbol on the binding stack, and then accessing its
tls-index to unbind it, save the tls-index directly, saving one memory
read.
That is, in the texinfo files of the user manual, the internals manual,
and in sbcl.1. Fix spelling and grammar errors, put sufficiently many
dots in abbreviations and consistently write "SBCL" in all caps in
prose. Also, SIGABORT should be SIGABRT.
Instead of JMPing to TARGET, CALL a trampoline that saves the return
pc and jumps. Although this is an incredibly stupid trick, the paired
CALL/RET instructions are a big win.
Forward port of Alastair Bridgewater's patch.
Duplicate it on x86-64.
Make it so that fp points to ocfp just as if the call had been made by
CALL to a function with the standard prologue "PUSH EBP; MOV ESP,
EBP".
Fix the debugger.
Forward port of Alastair Bridgewater's patch. Also, port it to x86-64.
Bring x86 and x86-64 sources closer in the process.
Plus cleanups, indentation, remove dead code, comments, more checks.
All non-win32 platforms converted to use normal signals
(SIGINFO/SIGPWR) to implement INTERRUPT-THREAD.
Remove mention of RT signals from the internals manual.
- fix compilation with QSHOW
- SHOW prints thread id on threaded builds
- SHOWing os_threads
- do not print pthread_self() that's the job of SHOW
- always print thread ids with %lu
- states with %x
- add more SHOW to ease debugging
- gc_stop_the_world: don't flood with FSHOW_SIGNAL when waiting for
another thread to change states
- signal safe SHOW
(if QSHOW_SAFE is defined)
* Add WITHOUT-INTERRUPTS to WITHOUT-GCING.
* Warn if WITH-INTERRUPTS nested in WITHOUT-GCING.
* Make sure that SIG_STOP_FOR_GC and SIG_RESUME_FROM_GC are enabled on
threaded builds before calling into SUB-GC from the runtime.
* Better WITHOUT-GCING, WITHOUT-INTERRUPTS, and WITH-INTERRUPTS
documentation.
* Internals documentation about POSIX signal safety rules.
Explicitly disallow specializations on new-value for (setf
slot-value-using-class), as suggested by Levente Mezaros
sbcl-devel 2006-05-09.
... documentation
... internals documentation
... also one or two other small cleanups: don't keep dfun
information in special-case generic functions; make
metaobject-protocol-violation an error, not just a
condition.
Merge patch from James Bielman fixing self-build under Win32.
... a little bit of an accident ensued; I ran
canonicalize-whitespace on .sh files, which seemed to
work (except on wc.sh) until it scribbled all over
make.sh, confusing the shell interpreter utterly.
... the resulting files have built the system, nevertheless.
Add documentation of the various SLOT-VALUEish optimizations
performed.
... and some FIXMEs where either (a) I'm not sure what's going on
or (b) something fishy is happening.
Document what we've learnt about discriminating functions
in the internals manual
... now we depend on dot (graphviz) to draw pretty state
transition graphs.
... lots o' text. I hope it's clear.
(it would be good to upload this to the web somewhere, in
order to be the top hit for e.g. "PCL CONSTANT-VALUE" on search
engines, so that the next person to hit the swamp has a chance
to get out before it's too late. Hack the Makefile enough so
that we can build an html version of an internals manual.)
* rename FOREIGN-SYMBOL-ADDRESS => FOREIGN-SYMBOL-SAP,
FOREIGN-SYMBOL-ADDRESS-AS-INTEGER => FOREIGN-SYMBOL-ADDRESS, and
so forth. Follow this scheme consistently, calling foreign saps
saps, and addresses addresses.
* split GET-DYNAMIC-FOREIGN-SYMBOL-ADDRESS into
FIND-DYNAMIC-FOREIGN-SYMBOL-ADDRESS and
ENSURE-DYNAMIC-FOREIGN-SYMBOL-ADDRESS.
* new function: FIND-FOREIGN-SYMBOL-ADDRESS, which doesn't enter
the symbol to linkage table. Use it in SB-POSIX to detect the
presence of foreign symbols.
* merge patch by David Lichteblau:
ENSURE-DYNAMIC-FOREIGN-SYMBOL-ADDRESS keeps track of used foreign
symbols in hash-tables instead of lists.
