A few comments.
* Is there ever any need to for a PMC type which holds both an int and a
num? In the Perl 5 case we were constrained by code that expected to always
find an int (or a num) in a fixed slot in the SV; with PMCs, all access
to these slots is via methods, so an int-num or num-int conversion can
be done on the fly.
* like Dan, I think that for at least the common cases, the payload
should be stored in the PMC's cache. We want common PMCs types to fit
directly in the cache, without needing a separate alloc and indirection.
* I think that the cache of a PMC ought to be more flexible, eg replace
DPOINTER *data;
union {
INTVAL int_val;
FLOATVAL num_val;
DPOINTER *struct_val;
} cache;
with something like
union {
INTVAL int_val;
FLOATVAL num_val;
DPOINTER *struct_val;
} cache[2];
(note the '[2]')
and where the 2 may become 3 or whatever depending on later profiling.
There shopuld be a pair of flag bits for each cache entry to tell the
GC whether that cache entry holds a GC-able ptr, and if so, whether it
is to a PMC or a buffer.
Dave M.
