Subject: Re: Buggy BinarySearch implementation, real life and a curious soul...
From: (Rob Warnock)
Date: Fri, 09 Jun 2006 21:55:29 -0500
Newsgroups: comp.lang.lisp
Message-ID: <> <> wrote:
| And then there is x86-64...
| This is SBCL 0.9.12, an implementation of ANSI Common Lisp.
| 1152921504606846975
| * (log most-positive-fixnum 2)
| 60.0

I suspect this was done for the same reason that 32-bit CMUCL
reports (log most-positive-fixnum 2) ==> 29, so that a fixnum "1"
is an underlying machine integer whose value is the length of a
"lispobj", i.e., 4 for 32 bits and 8 for 64 bits. That permits
array elements to be indexed by a fixnum by simply adding the
fixnum (maybe with a one or two element offset) to the address
of the array, as "cmucl/src/docs/internals/internal-design.txt"

    Effectively, there is one tag for immediate integers, two zeros.
    This buys one more bit for fixnums, and now when these numbers
    index into simple-vectors or offset into memory, they point to
    word boundaries on 32-bit, byte-addressable machines.  That is,
    no shifting need occur to use the number directly as an offset.

    This format has another advantage on byte-addressable machines
    when fixnums are offsets into vector-like data-blocks, including
    structures.  Even though we previously mentioned data-blocks are
    dual-word aligned, most indexing and slot accessing is word
    aligned, and so are fixnums with effectively two tag bits.

Preserving this useful characteristic on a 64-bit machine means
using a "three zero bits" lowtag for fixnums there, which is what
SBCL appears to have done.


Rob Warnock			<>
627 26th Avenue			<URL:>
San Mateo, CA 94403		(650)572-2607