Looking at the PerlInt vtable ops, do we have the worst case backwards? (Or, more to the point, are we missing the worst case?)
new P0, PerlNum new P1, PerlString new P2, PerlInt new P3, PerlGork # A new PMC set P0, 1.23 set P1, "4.56" set P2, 7 set P3, 8.910 # Whatever that means in PerlGork-speak Now, if we add a PerlNum to a PerlInt: add P4, P2, P0 we get a PerlNum back in P4. If we add a PerlString to a PerlInt: add P4, P2, P1 we get either a PerlNum or a PerlInt back, depending on how the number can be represented. If we add a PerlInt to a PerlInt, add P4, P2, P2 we, of course, get a PerlInt back. But if we add a PMC_Other type - here, PerlGork - to a PerlInt add P4, P2, P3 we also get a PerlInt back, which loses whatever Gorkiness we had preserved. Since we've a limited number of base types, I don't think that this is the behavior that we want - it's trivial and almost required for user-defined vtables to be able to interact (preservingly) with the basic PMCs, and I think that we should angle towards base type promotion, rather than the current demotion to base types. The assembler can't always guarantee the "higher" type comes first, ensuring its vtable is called prior to the base types, mainly because of the lack of strong typing. That means that base types are going to have to revector an equivalent call through the PMC_Other's vtable. In the event of two different PMC_Other's, I think we can get away with arbitrarily choosing one or the other. On a completely unrelated note, I did some low-level profiling of pmcmops on Sparc. The good news is that there are few slow spots. The bad news is those slow spots are save/restore instructions on function entry and exit (along with the requisite jmpl instructions from the indirection) and the dereferencing of an indirected indirection. N&Z-semantic logical ops seem to also take the occasional hit, which I haven't figured out yet. -- Bryan C. Warnock [EMAIL PROTECTED]
