At 06:24 PM 8/5/00 -0400, Ken Fox wrote:
>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.
Perl rarely does this. :)
Not, though, that we can't in the future.
>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.
The thread sync stuff needs to be out in the constant area of the variable.
(Been there, done that. Got a non-threadsafe lock() because we didn't) The
sv_any pointer's there for the GC as much as anything else--the base sv
struct can't be moved since we store pointers to it, but the actual data
can be, so compaction GCs can run.
The rest is also there to optimize the common case. (Though I do think it's
overkill in many circumstances if all variables share the same base
structure--arrays don't really need an integer portion, neither do hashes)
That's not a bad thing and, like I said, the big win's not in optimizing
scalars, it's in optimizing hashes and arrays. Skimping here's likely not
worth it in the long run.
>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.
I'm certainly not guaranteeing that this is the best way to do things,
though it seems a good way, drawing on past experience.
>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.
I agree. That's why I yanked in the PMC designation. :-)
> > 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!)
The vtable routines. If a scalar changes implementation, they change the
vtable for it. So, for example, when the integer array code is required to
promote an element to a full scalar, it promotes the whole array then
changes the vtable pointer to point to the scalar array vtable.
Flags are still needed, since there will be some generic state--is the
pointer valid, can it be moved, is the representation fixed or changeable,
stuff like that. The number of flags may well be very limited, with most of
the flag functionality subsumed by vtable code, and that's OK by me.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
