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

[Tim Peters]

Backtracking:

[Aaron]
> I've always considered it a major shame that Python ints and floats
> and chars and stuff have anything to do with dynamic allocation ...

[Guido]
> What you're describing is very close to what I recall I once read
> about the runtime organization of Icon.  Perl may also use a variant
> on this (it has fixed-length object headers). ...

I've rarely been able to make sense of Perl's source code, but gave it
another try anyway.  An hour later I gave up unenlightened, so cruised the
web.  Turns out there's a *terrific* writeup of Perl's type representation
at:

    http://home.sol.no/~aas/perl/guts/

Pictures and everything <wink>.  Header is 3 words:  An 8-bit "type" field,
24 baffling flag bits (e.g., flag #14 is "BREAK -- refcnt is artificially
low"(!)), 32 refcount bits, and a 32-bit pointer field.

Appears that the pointer field is always a real (although possibly NULL)
pointer.  Plain ints have type code SvIV, and the pointer then points to a
bogus address, but where that address + 3 words points to the actual integer
value.  Why?  Because then they can use the same offset to get to the int as
when the type is SvPVIV, which is the combined string/integer type, and
needs three words (to point to the string start address, current len and
allocated len) in addition to the integer value at the end.  So why is the
integer value at the end?  So the same offsets work for the SvPV type, which
is solely a string descriptor.  So why is it important that SvPVIV, SvPV and
SvIV all have the same layout?  So that either of the latter types can be
dynamically "upgraded" to SvPVIV (when a string is converted to int or vice
versa; Perl then holds on to both representations internally) by plugging in
a new type code and fiddling some of the baffling flag bits.

Brr.  I have no idea how they manage to keep Perl running!

and-not-entirely-sure-that-they-do-ly y'rs  - tim