On Thu, Apr 13, 2006 at 01:55:28AM +0200, Leopold Toetsch wrote:
> On Apr 11, 2006, at 19:03, Chip Salzenberg wrote:
> >2. "Reference Model" for value objects
> > In Parrot, this mostly amounts to unique read-only PMCs.
> > We'll have the read-only part, but the "unique" part, probably not.
>
> Can I/we read this as: "morphing for Parrot core PMCs is history"? - Or
> in other words: differently sized PMCs (with a common (PObj) header) is
> the way to go?
Heh. When I want to say that, I think I know how to be clear. :-)
But on the subject of PMC restructuring:
* Your description of the status quo is that every access to the class-
specific data in a PMC, e.g. to the array elements of a PMC array,
require three indirections: One to the PMC, one to the PMC_EXT, and then
one more to the user-defined data.
But: I see extensive use of PMC_(struct|pmc|int|num|str)_val() in *.pmc.
So triple indirection is hardly universal. Granted it is necessary for
some cases, but the situation isn't as unliveable as I understood you to
say earlier.
+ BTW, I don't see any use of PObj_buf(start|len) in *.pmc, and I find
this odd. Surely there must be PMCs that would find it helpful to
have both a pointer and a length without additional indirections...?
* A consequence of variable-length PMCs would be a merging of PMC_EXT into
PMC.
Why wait for variable-length PMCs to get rid of PMC_EXT? Doing so now
would eliminate an indirection and a pointer, which should help according
to your theory.
I'm told that PMC_EXT was introduced to help cache line behavior, but if
I read the tea leaves^W^Wsource code correctly, sizeof(PMC) is right now
five words on a 32-bit machine, an odd choice -- it should be possible to
hit eight words instead, which ought to be cache-friendlier.
--
Chip Salzenberg <[EMAIL PROTECTED]>
