Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 5:17 PM +0200 9/1/04, Leopold Toetsch wrote: >>Below is a pod document describing some IMHO worthwhile changes. I >>hope I didn't miss some issues that could inhibit the implementation.
> Okay, the "No" warrants more explanation. Thanks. > First off, the current structure of PMCs, Buffers, and Strings is > definitely a mess, what with the multiple nested structs, semi-shared > data, and weird smallobject overlap. A lot of stuff that is, in > retrospect, crap has been layered on, so if this gets beaten up and > cleaned out I won't mind in the least. Well, that's what the proposal is for. Cleaning up and unifying existing mess. > The PMC scheme -- where PMCs are an immovable header with a vtable > slot, cache slot, and flag slot -- stays. It's this way on purpose, > and matches normal usage patterns (nicely efficiently) for perl 5 as > well as (oddly) most python and ruby usage. (Where there's a > preponderance of low-level types) I don't see that "matches normal usage patterns". Just the opposite of it. The current PMC structure doesn't easily allow to create e.g. Pythons "all is an object" POV. An Integer just needs 2 words of information and not more. The rest (3 words) is just wasted. No interpreter I've looked at has fixed sized objects. OTOH aggregates have artifical helper structures to store needed information. A variable sized PMC covers that all and eliminates all indirections totally to access these data. I don't see efficiency either, neither in execution time nor in memory usage in the current scheme. > Buffers and strings are special-purpose constructs, or at least they > *should* be. They're segregated off for GC purposes. Buffers and strings are different because the current PMC structure doesn't allow or support an arbitrary object layout. This lack of functionality creates the need for Buffers. Which leads to more indirection in accessing an PMC's data and more overhead during GC. The unificiation into one coherent object model just simplifies all that stuff. > ... While they could > be unified with PMCs, I don't want them to be. They've specific, > special purposes, and as such they're staying the way they are. A PMC is specific enough. The vtable makes it special. The vtable defines the functionality of that very object. There isn't any real difference between an Buffer structure or an array-ish PMC. Both hold some amount of data. But we currently treat these two totally differently for no good reason. > Strings, FWIW, are *not* a perl 6 specific thing. The current string > design is sufficient, and *will* be used, for perl 5, python, and > ruby, as well as any other language that wants to live on parrot and > handle string data. While there's stuff to be added still, there's no > reason that I can see to mess with them. Well, the current need for a distinct STRING type arises just because of a lack in PMCs to deal with strings. E.g. $P0 = a_func_returning_a_string() $S0 = $P0 $I0 = length $S0 That's the way to get at the length of a string. Python doesn't have a notion of a STRING, I'm not aware of anything like that in Perl5 either. So functions are returning objects aka PMCS. Mostly all operations are dealing with PMCs only. This is my experience coming from the Pie-thon quest, but not alone. The need for STRING opcodes and vtable/MMD functions just comes from a lack of functionality in PMCs. Unifying or just having String PMCs eliminates this lack and almost one third of opcodes. STRING operations aren't the fastest anyway. I don't see any reason to just provide all these in PMCs (which we need anyway) and eliminate the duplication with a distinct type. Native integers and numbers do warrant the specialization. Processors and JIT can supprt these types natively. Nothing can be done with STRINGs*. These are just overhead and code duplication currently. > Finally, Nicholas is right -- this is messing around with stuff that > already works. We're better off working on things that don't exist > yet, and leave this to later. That's of course true. There is a lot of stuff that needs to be done and should be done before reworking internals deeply. OTOH a lot of currently todo stuff could immediately be done much more easily. We need some more PMCs e.g. to manage packfiles and code segments. The rigid structure of the fixed-sized PMCs is always a PITA when implementing new objects. Unicode string vtables is another issue, albeit I don't know, if some/all vtable slots are usable for string operations. But we got already e.g. concatenate or bitwise string vtables. > If you want, we can hash out the changes to sub calling (with the > swapping interpreter structs we've been arguing over), moving the > return continuation/calling object/called sub into the interp > structure, Of course, yes. That thread is BTW lacking another answer: what's the difference between your derived proposal and mine. > ... and fixing up the JIT and exception handling stuff to deal > with it. That, at least, will be visible to bytecode programs and > worth getting done. Yep. leo
