>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 01:13 PM 6/13/2001 +0200, Bart Lateur wrote:
>> On Tue, 12 Jun 2001 18:12:35 -0400, Dan Sugalski wrote:
>>
>> >'Kay, here's a question to ponder. Should the op dispatch loop handle
>> >argument decoding, or should that be left to the opcode functions?
>>
>> Are you talking about lazy vs. normal evaluation?
DS> Nope. That's a separate issue. This is more "Does an opcode get passed a
DS> register number or a pointer" one.
<late on this thread as i was offline>
i think that the op functions should be passed PMC pointers
directly. this will allow for later translation into TIL code with no
change to the functions. the only code that needs to know about the
registers and stack(s) should be the op code dispatcher. it take the
register numbers (from the byte code) and converts them to PMC pointers,
looks up the op code function address in the dispatch table and calls
it. this also hides all of the register design and implementation from
the other internals which allows for a more modular design. we could
even change the register design later during development and not touch
the functions. also access to the functions via XS (or rather,
InLine::Foo) would be simpler with a PMC pointer interface than a
register one since you wouldn't have all that duplicate register
decoding code everywhere.
so the basic idea is that only the op code dispatcher (and the byte code
generation pass) knows about registers and related stuff.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- 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.html
