Why waste space on flags? The vtbl should handle that. There are a limited
number of valid combinations, the vtbl could alter the behavior and
trading space for speed, no need to check flags. Alter the vtbl instead.
(Perhaps a simple state machine.)
And why waste the GC data. I suspect that most variables will not be shared.
Put the sync data into a seperate area and then access the external data.
If the sync data is in the SV, I believe there is a race condition between
the destruction and grabbing a lock.
And why carry around IV/NV and ptr? Make it into a union, to allow room.
The string/number duality should be handled by the vtbl. So a string
that is never accessed as a number, doesn't waste the space. And
numbers that are rarely accessed as a string save some room. And
as needed the vtbl can be promoted to a duality version that maintains
both.
<chaim>
>>>>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> So my own favourite right now allows a little more - to keep data and token
NI> together for cache, and to avoid extra malloc() in simple cases.
NI> Some variant like:
NI> struct {
NI> vtable_t *vtable; // _new_ - explcit type
NI> IV flags; // sv_flags
NI> void *sync_data; // _new_ - for threads etc.
NI> IV GC_data; // REFCNT
NI> void *ptr; // SvPV, SvRV
NI> IV iv; // SvIV, SvCUR/SvOFF
NI> NV nv; // SvNV
NI> }
NI> The other extreme might be just a pointer with LS 3 bits snaffled for
NI> "mark" and two "vital" flags - but that just means above lives via the
NI> pointer and everything is one more de-ref away _AND_ needs masking
NI> except for "all flags zero" case (which had better be the common one).
NI> As I recall my LISP it has two pointers + flags
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
