Nick Ing-Simmons wrote:
> I am tempted to turn that round - have the vtable pointer in the SV *,
> and the type code (if we need it) in the vtable - that saves a deref on
> dispatch - where we need speed - and still allows type code access for
> meta ops.
I was thinking about the case where someone wants to optimize for memory
usage rather than speed. It's quite feasible to get an SV struct down to
two words, but at the expense of a lot of bit shifts and limitations on
the GC system.
This got me thinking about whether it's necessary to define exactly what
an SV struct is. The following seems over-specified:
> typedef struct p6SVBASE
> {
> p6vtable *vtable;
> u32 iFlags;
> union {
> struct {
> void *ptr;
> IV iv;
> } words;
> NV nv;
> } data;
> } p6SVBASE;
Dan's struct that includes thread sync stuff is also over-specified.
I think the only thing we have to standardize on is the vtable interface
and the flags. This seems like a good thing, at least during early
experimentation with perl 6.
We could wrap the basic operations on an SV with inlines so that the
abstraction won't kill performance. The entire low-level definition of SV
could be done in a header file. When building perl just pick what header
you want. This would have no effect on external modules since they all go
through the public interface.
BTW, SV isn't a good name for this struct. It's really a value
binding, not the value itself. IMHO it would be a lot easier to read the
code if we clearly differentiated between what's now called SV and the
collection of xpv*'s.
> inline IV
> SvIV(SV *sv)
> {
> return (*sv->vtable.SvIV)(sv);
> }
>
> With the simplest case being
>
> IV
> nativeIV(SV *sv)
> {
> return sv->data.words.iv;
> }
What component of the system is responsible for representation
shifting? It might be a really clean design for us to always shift
representations so that the current vtable always points to the
corrent semantics. (Look, ma, no flags required!)
- Ken
