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 <dan@sidhe.org> 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 > dan@sidhe.org have teddy bears and even > teddy bears get drunkThread Previous | Thread Next