[Python-Dev] stackable ints [stupid idea (ignore) :v]
Barry A. Warsaw
bwarsaw at cnri.reston.va.us
Thu Jun 10 20:02:30 CEST 1999
>>>>> "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
More information about the Python-Dev
mailing list