Front page | perl.perl6.internals |
Postings from September 2001
Thanks for the info. If you guys maintain this level of documentation as the code develops, Perl 6 will be easy for first-timers to work on. One goal down, N-1 to go... ;) Simon Cozens wrote: > To be more specific about the software CPU, it will contain a large > number of registers. The register frames store values, not pointers to values? If there's another level of indirection with registers, I'm not sure what the advantage is over just pointing into the heap. Also, heap based activation records might be faster and more compact than register files. > As in Perl, Parrot ops will return the pointer to the next operation in > the bytecode stream. Although ops will have a predetermined number and > size of arguments, it's cheaper to have the individual ops skip over > their arguments returning the next operation, rather than looking up in > a table the number of bytes to skip over for a given opcode. This seems to limit the implementation possibilities a lot. Won't a TIL use direct goto's instead of returning the next op address? I'd like to see a description of *just* the opcode stream and have a second section describe the protocol for implementing the ops. Won't we have separate implementations of the opcode interpreter that are optimized for certain machines? (I'd at least like to see that possibility!) > =head1 Vtables > > The way we achieve this abstraction is to assign to each PMC a set of > function pointers that determine how it ought to behave when asked to do Damian's proposals for multi-methods have got me thinking there should be one very fast implementation of multi-method dispatching used at the opcode level. It might help solve some of our math and string problems dealing with mixed operand types. - KenThread Previous | Thread Next