At 09:55 AM 4/23/2001 +0100, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >At 07:39 PM 4/19/2001 +0000, [EMAIL PROTECTED] wrote:
> >>Depends what they are. The scheme effectively makes the part "mandatory"
> >>as we will have allocated space whether used or not.
> >
> >Well, we were talking about all PMCs having an int, float, and pointer
> >part, so it's not like we'd be adding anything. Segregating them out might
> >make things faster for those cases where we don't actually care about the
> >data. OTOH that might be a trivially small percentage of the times the
> >PMC's accessed, so...
>
>What is the plan for arrays these days? - if the float parts
>of the N*100 entries in a perl5-oid AV were collected you might
>get "packed" arrays by the back door.
Unless Larry says otherwise, this:
my num @foo;
will have the data portion of the @foo PMC point off to a block of memory
with floats jammed end-to-end in it.
> >I was trying to avoid embedding the offset in the PMC itself. Since it was
> >calculatable, it seemed a waste of space.
>
>But passing extra args around is fairly expensive when they are
>seldom going to be used. Passing an extra arg through N-levels is
>going to consume instructions and N * 32 bits of memory or so.
Yeah, you're right. I think the better thing to do is force the alignment
of the PMC arena pieces and mask off the low bits for the base address, or
the high bits for the current array index. I'm going to go update the GC
PDD in a bit with this. (So long variable arena sizes, but that's probably
for the best all things considered)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
