>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Yeah, I can't think of a good reason for a noop. We might have one
DS> anyway, though, just in case one comes along anyway.
in a hardware cpu they were commonly used to fill an instruction slot to
keep a pipeline filled, or to follow a branch decision, or to pad a long
running op. in parrot, those timing issues don't exist. we have no
critical penalty with instruction ordering or branching. but then a NOP
would be as trivial as:
int NOP( int PC ) { return PC + 4 }
assuming 4 byte op codes.
>> Here's a dumb question: will parrot allow bytecode which is stored in a
>> perl scalar to be executed?
DS> Yup, in a restricted sandbox too, if you want. That way we'll be
DS> able to serialize code to bytestreams, spit them across the 'net,
DS> and execute them on the other end.
will the op code table need to be sent over if it is code from a module
which defines new op codes? what about different versions of perl6, will
they always use the same op code numbers? what about relocation and the
cleanup section of modules?
inquiring minds want to know,
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs -------------------------- http://jobs.perl.org
