APW was great. I talked about the Parrot project, and its goals and priorities. Please read it, either the OpenOffice version or the PDF export version.
Yesterday was the first day of the post-APW hackathon, and it was quite a day ... it started off with heavy design discussion and ended with me wandering around in a daze. Not that that's unusual, really.
Variable-length register frames were an early topic. Register spillage is inevitable when you have a limited number of registers in your machine. However ... and work with me on this ... Parrot is a virtual machine. We don't have a limited number of registers, unless we want to, and I'm pretty sure we don't.
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 ... I totally missed watching the Austrian countryside as I explained the Perl 5 lexical implementation to Leo and Autrijus. Turns out that Perl 5 is actually an improvement on Parrot right now: Perl 5 knows that lexicals' names and scopes are known at compile time, so it compiles them then and never revisits them. Parrot, in contrast, actually builds and destroys the list of lexicals at runtime. Silly, isn't it? Well, that'll change. We'll have separate data structures for the names and scopes of lexicals (static) and their values (dynamic, created at subroutine entry (probably)).
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!
Re:PIR registers
chip on 2005-06-16T13:13:27
You're right, the available universe of registers is infinite in theory. But any given subroutine's register frame size will be set at compile time, so the entire frame's size can be known and JIT code can access registers of all types using fixed offsets from a single hardware register, just as now.BTW, that link doesn't work. At least from Austria.
:-(
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.
I don’t understand this move at all. You just said that Parrot is a virtual machine yourself. The hardware and the software it runs are both software. The only difference between opcodes and library calls is how quickly they can be invoked. Why would you take a performance penalty for invoking functions for no good reason?
