Mike,
Part of the beauty of PMCs is that you can have very compact storage given a dedicated eg int array type. Generating these would not be a bad thing. The typical case still remains, that arrays will contained mixtures of all datatypes. On Wed, 24 Jul 2002, Mike Lambert wrote: > This patch is rather questionable, and thus I did not commit it > directly. However, it illustrates a point I wanted to make. > > As mentioned in my recent PARROT QUESTIONS email, a lot of the clutter in > the PMC aggregates can be removed with the use of redirecting functions. > > The below patch reduces the resulting array.c from 40K to 20K, and the > ..obj file from 25K to 33K (not that much). > > It introduces another layer of recursion into the code, while at the same > time eliminating lots of duplicate code. If we disallow subclassing of the > PMC, a lot of the vtable redirects in this code could be replaced with > straight function calls (and those function calls could subsequently be > inlined within the same .c file). Please, please take a moment to review my earlier posts about refactoring the PMC API. Cleaning up the code isn't a bad thing, but I think there is a deeper problem. I proposed several approaches. Taking just one of them: Requests to operate on PMCs should not be propogated down to the PMC through one of dozens of methods. Instead, the PMC should be fetched into a scratch register and operated on directly. In the case of primitive atomic datatypes, the recurisve multiply, add, div, etc operations should be disposed of, and references to the atomic types should be fetched to a scratch register, where they are operated on directly (as a reference). This would require more .ops permutations, but would grossly simplify the PMC API and shrink the code dramatically. Other proposals were slightly more complicated but avoided the permutations of ops problem. Restating, if you're going to work on this, please work with me. I'd be glad to help whatever you're doing, but I *hate* duplication of effort. I've got plenty of other things I should be working on. > > After doing this, I wonder if it's not useful to allow an aggregate PMC to > declare its inner type (in this case, PMC). The pmc2c.pl would then > generate stub functions which converted from that base type to each of the > requested types. This would allow PerlIntArraty to be a base of INT, yet > perform auto-conversions to num, string, pmc, etc in the generated code. > > Is the patch here too recursive to be efficient, despite the reduction in > actual code? Should all SELF->vtable methods on *.pmc files be made to > call the appropriate function directly, and assume no subclassing? I know its hard to get a yes/no opinion on a patch. People always want to "address the bigger issue". I'd love to hash this out with you. However, my reaction would be, yes, we should have IntArray, NumArray, PMCArray generated from a template, I personally would avoid more levels of function nesting, but I feel much more strongly about seperating lookup and the operation. > > Another possibility is to regenerate the functions for the subclasses, so > that parent inlinings of SELF->vtable->get_pmc_keyed will not interfere > with a child's redefinition of their own get_pmc_keyed ? The 33k implementation of Array is less then 1/4 complete. This beast will be 125k before its done, mark my words. Low power chips have quarter meg or half meg L2 caches. I'm a firm believer that a VM should fit in cache and leave room for some data to be cached, too. A seperate fetch and operation would add a few more instructions to the implementation, but compared to the cost of a cache stall, this is beans. The best thing we could do is remove some of this bloat now. > > Thoughts, comments? yes =) > Mike Lambert > Mike, I can't mail you directly. I'm sharing a netblock with a known spammer and you're using spews.org. I didn't mean to send my rant to the entire list again. Sorry, folks =( -scott
