Subject: Re: Buggy BinarySearch implementation, real life and a curious soul...
From: rpw3@rpw3.org (Rob Warnock)
Date: Fri, 09 Jun 2006 21:55:29 -0500
Newsgroups: comp.lang.lisp
Message-ID: <ILmdnfr1D7I8qRfZnZ2dnUVZ_tqdnZ2d@speakeasy.net>
pbunyk@gmail.com <pbunyk@gmail.com> 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"
says:

    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

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607