There are comments saying that the high 2 bits of code-header-widetag
must be zero. I didn't want to figure out whether that's still
a requirement. So pick widetags that make it true.
i.e. do not fail if the host lisp isn't found, barring any other failures.
Intuitively the check for a host lisp belongs in 'make.sh', but the rationale
for putting it in make-config is that failing sooner makes sense if the build
can't begin. But it was an incorrect behavior for make-config when run at the
shell prompt while trying to diagnose problems in that script.
I noticed this when fixing the recently discovered bug in pscav_later -
users could too easily create pointers from read-only space to dynamic space
which would have crashed at some later time. The only slot that could be
portably set is the docstring, via (setf (documentation #'fun t) "something"),
for which a full warning seem appropriate since that's less harmful than
heap corruption. This is a long-standing issue having nothing to do with
the recent alterations to simple-fun headers.
Based on paper by Tim Harris @ https://timharris.uk/papers/2001-disc.pdf.
The algorithm depends on arbitrarily manipulation of 1 bit of a pointer
which we can do by relaxing the tagging requirement for pointers from a
node to its successor. For technical reasons, our representation differs
from that in the reference paper - for us, the lowtag bits of a successor
pointer are either all correct (INSTANCE_POINTER_LOWTAG), or all 0.
The code has been lightly exercised on arm64, ppc, x86, and x86-64.
I'm still deciding on the interface that we want to expose,
and where such lists can be used internally.