Front page | perl.perl6.internals |
Postings from May 2001
>>>>> "DS" == Dan Sugalski <dan@sidhe.org> writes: DS> The size of the generated bytecode's likely not going to be DS> directly an issue in determining speed. (And we can't count on DS> keep the locals exclusively in the register set either, as DS> otherwise string eval won't be able to find them, and neither will DS> the debugger) but if registers are usually just a PMC pointer, that address can also be accessed through the symbol table or pad or whatever. in my view what the compiler is doing with registers is actually aliasing a register index to some PMC somewhere. a load register doesn't copy the PMC, just its address into the register slot. this whole purpose of the register system is to support a simple bytecode with integer offsets for arguments. that bytecode format has many postive qualities so we should try to make the IL map well to it. the register idea is not a speed thing in and of itself. the registers are the logical way the VM operates on data. fetching a global may require an operations such as a symbol lookup and load the PMC into a register. the compiler tracks register usage and does the push/pops to manage them. DS> We still may have synchronization issues with threads and lexicals, but DS> likely far less than with globals. by keeping all thread specific data in a single data structure, then only global accesses will need to be synchronized. i think the VM data (stack, registers, PC, etc.) will be a part of this per thread data block. uri -- Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11 Class and Registration info: http://www.sysarch.com/perl/OOP_class.htmlThread Previous | Thread Next