CLISP implements two ways of representing object pointers. (An object pointer, C type object, contains a pointer to the memory location of the object, or - for immediate object - all bits of the object itself.) Both of them have some things in common:
CHARACTER
s, FIXNUM
s, SHORT-FLOAT
s, etc) and
heap allocated objects.CHANGE-CLASS
is called. To avoid scanning all the heap for
references when this happens, the class information is stored in the
heap allocated object, not in the object pointer.The HEAPCODES
object representation has a minimum of type
bits in the object pointer, namely, 2 bits. They allow to distinguish
immediate objects (which have some more type bits), CONS
es (which
have no type bits in the heap, since they occupy just two words in the
heap, with no header), other heap objects (many, from SIMPLE-VECTOR
s
to FFI:FOREIGN-POINTER
s), and Subrs. Most object types are
distinguished by looking a the rectype
field
in the header of the heap object.
The TYPECODES
object representation has about two dozen of types
encoded in 6 or 7 bits in the object pointer.
Typically these are the upper 8 bits of a word (on a 32-bit machine) or
the upper 16 bits or 32 bits of a word (on a 64-bit machine).
The particular values of the typecodes allow many common operations to
be performed with a single bit test (e.g. CONSP
and MINUSP
for a
REAL
are bit tests) or range check.
However, the rectype
field still exists for
many types, because there are many built-in types which do not need a
particularly fast type test.
Which object representation is chosen is decided at build time
depending on the available preprocessor definitions. You can define
TYPECODES
or HEAPCODES
to force one or the other.
One might expect that TYPECODES
is faster than HEAPCODES
because it does not need to make as many memory accesses. This effect
is, however, hardly measurable in practice (certainly not more than 5%
faster). Apparently because, first, the situations where the type of an
object is requested but then the object is not looked into are rare.
It is much more common to look into an object, regardless of its type.
Second, due to the existence of data caches in the CPU, accessing a heap
location twice, once for the type test and then immediately afterwards
for the data, is not significantly slower than just accessing the
data.
TYPECODES
is problematic on 32-bit machines, when you want to
use more than 16 MB of memory, because the type bits (at bit 31..24)
interfere with the bits of a heap address. For this reason,
HEAPCODES
is the default on 32-bit platforms.
HEAPCODES
is problematic on platforms whose object alignment
is less than 4. This affects only the mc680x0 CPU; however, here the
alignment can usually be guaranteed through some gcc options.
These notes document CLISP version 2.49 | Last modified: 2010-07-07 |