Front page | perl.perl6.internals |
Postings from November 2001
Simon just chastised me for talking instead of patching. Most of the stuff I'm interested in is heavily related to the implementation of lexicals, so that's where I'm going to jump in. There are a number of decisions to make about lexicals and the current PDD is pretty slim. So, IMHO, the place to start is with the PDD. Anybody have any more thoughts on the interface? Dan? Is this stone tablet stuff yet? The big five questions on my list are: 1. The find_lex/fetch_lex ops push a lot of work into the run-time when the compiler can figure out what frame a lexical appears in. Should there be an alternative, faster interface to lexicals that eliminates string lookups? The symbolic interface is required to support %MY and debugging, so it stays regardless of whether other interfaces exist. 2. Perl 5 doesn't support nested subs, but I haven't read anything about Perl 6 and I don't know if other targets for Parrot support them either. Do we want to support nested subs? Efficiently? 3. We've adopted a register machine architecture to reduce push/pop stack traffic. Register save/load traffic is similar, but not nearly as bad. Do we want to further reduce memory moves by allowing ops to work directly on lexicals? 4. There has been discussion about how useful non-PMC registers will be to the Perl compiler. If there are questions there, surely non-PMC lexicals would be even less useful to Perl. Do we want non-PMC lexical support? 5. Perl 5 uses pads and scratchpads for holding lexicals. Do we want to consider other implementations such as traditional stack frames with a display or static link? I'm leaning towards yes on all questions. If there aren't any obvious answers, I propose that we implement a couple different approaches and objectively compare them. Lexical implementation is as critical to Perl's performance as the dispatcher is, so we should take some time to get it right. - KenThread Next