On Mon, 2001-09-10 at 08:47, Dan Sugalski wrote:
> At 08:07 PM 9/9/2001 -0400, Uri Guttman wrote:
> > >>>>> "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.
>
> Yup, I realize that. I wasn't sure that we might not have some sort of
> in-memory opcode whiteout thing we need to do, in which case it'd be useful
> and potentially faster than recalculating a bunch of jump addresses.
>
> > >> 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?
>
> Basically we'll build a small "freeze to disk" section and send it over the
> wire instead of freezing to disk. It'll have all the standard stuff--fixup
> section, constants section, and code.
>
I was thinking about NOP this morning, and I realized that it might very
well be necessary. If someone was writing a "simple" assembler for
parrot, it might be useful for padding.
Brian
>
> Dan
>
> --------------------------------------"it's like this"-------------------
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
