Scott Walters wrote: > 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.
Yep, I agree. Thus, array.pmc would be 'the typical case', since its 100% PMCs. Stored integers and strings would be converted to PMCs for storage, much like how perl 5 works. > 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). Okay, I'll try and think this through. For normal aggregate PMCs, nothing more is required. The ops to fetch and store in scratch registers is available. And the ops to operate on them are there, too. For atomic types, it gets a bit stranger. We need to return references to these atomic types. This is problematic because: We don't have anywhere to store them. We can store them in INT registers (which I believe are guaranteed as large as pointers, but not sure), but then this gives us the ability to break the nonexistant "safe" interpreter by operating on the pointer. Finally, a whole complement set of ops needs to be generated. For every op like 'add N, N', we need an 'add Np, Np', where Np is NUM pointer. Or we need to "get" the NUM reference into an Nx register, operate on it, and copy it back into the INT pointer to the one in the aggregate. However, returning referencse does have one major advantage. Indicating the *lack* of something. If I retrieve a PMC which doesn't exist, I can get NULL back. But if I retrieve the 5th index of an integer array for which the length is 3, what am I supposed to get bacK? NaN? In this context, retrieving a pointer to the referred element makes sense, and allows us to "do things" to the keyed element, that aren't necessarily supported by the vtable methods. I'm beginning to agree with you, here. :) > 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. Oh, I hate duplication of effort, too. But the patch I sent in took 10-15 minutes to do, and I wanted to try it out and see how it reduced the code size. Besides, if you're complaining about how to do something, and you provide patches that start on it, I think people take you more seriously. :) > 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. I won't argue that it'll be 125K before it's done. In fact, I think it will be more. At least, if we continue on our current path of keyed versions of the various array methods. In terms of convincing Dan, I think we just need to be clearer in the argument: - the keyed approach is fine - get_keyed, set_keyed, are fine - the existing .ops for keys are fine, although more are needed The main changes that I see are: - the elimination of the keyed versions for all the mathematical vtable methods - the addition get_keyed_ref method - the addition of mathematical keyed *ops* that use get_keyed_ref to "do their thing" ? - perhaps some method for storing the keyed_ref result into a register? The mathematical keyed ops might make this unnecessary, however. Thoughts on this hopefully more concrete explanation of what could be changed? Thanks, 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 =( Sorry about that. I don't have control over the machine receiving email for me, and won't be back to serving my own mail until the fall semester starts up again.
