Yesterday was the first day of the post-APW hackathon, and it was quite a day
Variable-length register frames were an early topic. Register spillage is inevitable when you have a limited number of registers in your machine. However
PIR users will never notice the difference when register frames go all variable, since $P pseudo-registers were always infinite anyway. But things should get faster, and solving the problems of register allocation should be somewhat easier.
This is not a big deal to change, BTW. We even worked out how the JIT can handle it without loss of efficiency. Grabbing variable-sized hunks of memory is also basically a solved problem, what with, you know, strings and all.
(BTW, we have a new rule: PIR should be relatively stable, but it's OK to change pasm at any time, because humans should never write it. And fortunately it's not against the law to abuse silicon-based life forms.)
Calling conventions were the next topic. We'll have more specifics soon, but one thing Leo and I agree on is that the current convention is unnecessarily complex and an excessive burden on coders targeting Parrot. We're looking at abstracting it away from users so that all you have to write is "here are the arguments for the call I'm about to make" and "please put my incoming arguments in these registers".
Opcode count and policy was briefly discussed. The discussion was brief because Leo and I agree that the current opcode list is excessively broad. You don't make opcodes for all your IO and math and POSIX operations, for example. That's what libraries are for. So many opcodes will be migrating to standard libraries. Again, if you write PIR we can probably shield you from this change. PASM? You're on your own.
Lexical implementation was actually a topic before we got to Leo's
Well, today won't be nearly so high-powered, I'm sure. I'm focussing on documentation and the mailing list, and I'm going to get some details out of Leo on how we can implement these keen ideas, and how soon.
Share and enjoy!