RetroSearch Browse

Thu Jun 10 20:02:30 CEST 1999 · https://mail.python.org/pipermail/python-dev/1999-June/095364.html

>>>>> "Guido" == Guido van Rossum <guido at cnri.reston.va.us> writes:

    Guido> In ABC, we used a variation: objects were represented by
    Guido> pointers as in Python, except when the low bit was 1, in
    Guido> which case the remaining 31 bits were a "small int".

Very similar to how Emacs Lisp manages its type system, to which
XEmacs extended.  The following is from the XEmacs Internals
documentation[1].  XEmacs' object representation (on a 32 bit machine)
uses the top bit as a GC mark bit, followed by three type tag bits,
followed by a pointer or an integer:

      [ 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 ]
      [ 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 ]

        ^ <---> <------------------------------------------------------>
        |  tag         a pointer to a structure, or an integer
        |
        `---> mark bit

One of the 8 possible types representable by the tag bits, one is a
"record" type, which essentially allows an unlimited (well, 2^32)
number of data types.

As you might guess there are lots of interesting details and
limitations to this scheme, with lots of interesting macros in the C
code :).  Reading and debugging the C implementation gets fun too
(we'll ignore for the moment all the GCPRO'ing going on -- if you
think INCREF/DECREF is trouble prone, hah!).

Whether or not this is at all relevent for Python 2.0, it all seems to
work pretty well in (X)Emacs.

>>>>> "AW" == Aaron Watters <arw at ifu.net> writes:

    AW> ps: I suppose another gotcha is "when do you do
    AW> increfs/decrefs?"  because they no longer make sense for ints
    AW> in this case...  maybe add a flag to the type descriptor
    AW> "increfable" and assume that the typedescriptors are always in
    AW> the CPU cache (?). This would slow down increfs by a couple
    AW> cycles...  Would it be worth it?  Only the benchmark knows...
    AW> Another fix would be to put the refcount in the static side
    AW> with no speed penalty

    |      (typedescr
    |       repr* ----------------------> data
    |       refcount
    |      )

    AW>   but would that be wasteful of space?

Once again, you can move the refcount out of the objects, a la
NextStep.  Could save space and improve LOC for read-only objects.

-Barry

[1] The Internals documentation comes with XEmacs's Info
documetation.  Hit:

    C-h i m Internals RET m How RET

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/1999-June/095364.html below:

[Python-Dev] stackable ints [stupid idea (ignore) :v]