Mike,
Was very happy to see your message. People don't often agree with me. I'm not very agreeable. On Thu, 25 Jul 2002, Mike Lambert wrote: > 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. >From my limited understanding of Dan's philosphy, I'm guessing he would say that the speed penalty for promoting ints to PMCs just to be able to mix them would be unacceptable, and he would rather have the codebloat. As soon as you start mixing objects and not-an-objects, you've opened a huge can of worms. Promoting ints to PMCs solves this by getting rid of the not-an-object case. The other solution is the numerous permutations... I hope others have more productive thoughts on this =| Given strict compile time typing, the optimizer could pick from one of: IntArray, NumArray, StringArray, PMCArray, MixedArray. "Could" being the disoperative word. If they were available, a user could provide hints by explicitly specifying which he wanted. Storing a PMC in an IntArray would cause it to be downgraded. Having things available never hurts. > > 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. Haha, yeah, a different register file would have to be used when fetching references, if that were done. If they were fetched into the Int file, people could write Parrot could do poi... oooh! oooh! Gimmie! > > 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. :) > Promoting things to PMCs bring up an interesting point: a single instance of a certain PMC could be designated the "null PMC". As an int, a null PMC would "return 0;". It would be immutable and could be reused all over the place. It would be returned whenever a PMC was requested but the slot that would contain it contains nothing. Perhaps Parrot is already doing this and I completely missed it. Null pointers are a special case best avoided. Its better to have something always rather then something most of the time and not others. It could be compared to the official null object by pointer. Speed hack to deal with that case, nothing more. > 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? No. I'll have to write code. Seriously, thanks for your evaluation of this. It means a lot to me in the way of a sanity check. I also feel like I'm not just causing problems. I'll cook something up in a day or two as soon as I can get these damn paying clients off my back. When I submit something, it'll probably break all sorts of things I don't use or know about. Its also good to know that I'm not just horribly misunderstanding what I've read of the code and docs. -scott
