At 12:02 AM 7/10/2001 +0200, Paul Johnson wrote:
>On Mon, Jul 09, 2001 at 04:30:08PM -0400, Dan Sugalski wrote:
> > At 03:30 PM 7/9/2001 -0400, Uri Guttman wrote:
> > >definitely insert special opcodes only when asked for by a compiler
> > >option. stuff like profiling, tracing, fine grained single step (op
> > >code) debugging should be supported with special op code insertion upon
> > >user request.
> >
> > Nah, most of that doesn't need special support. We can piggyback on the
> > event pending flag. It'll be a UV, so there's no reason not to save a bit
> > for "debug". The event handler will never clear that, so we're fine.
> >
> > >but some special tasks still would want special op codes to be
> > >inserted. it would be simpler than piggy backing on only the ones you
> > >mentioned above. think about stuff like 'safe' or profiling or op code
> > >level debugging.
> >
> > Profiling and opcode debugging are covered in other ways (and the fanciest
> > is to have a special op running loop, which wouldn't be a bad idea).
>
>Well, that's what we have in Perl5, and it works fine until you have two
>modules both wanting to install their own runops function (not that that
>has necessarily happened yet).
Yeah, this is definitely a problem. There are some solutions to this, not
the least of which is to register an overridden event handling function,
but I'm not sure how it'd all work out. As you've said, nobody's done it
yet, but that might be because it's both arcane and difficult. It probably
ought be neither.
>I can also see similar sorts of problems with more than one module
>wanting to manipulate the "debug bit". I'm sure that can be worked
>around though.
Generally speaking, I don't have a problem with the declaration "Only one
debugging driver module at any one time".
> > Special ops to mark statement starts and such are probably going to happen
> > (so we have reasonable line numbers for error messages and such) now
> that I
> > think about it. Granted they get stripped out in some cases, but that's OK.
> >
> > It's also going to be very easy to override or supplement opcode
> functions,
> > and we're really going to be guaranteed some (end of statement and end of
> > block) are going to be there since we need cleanup, so it makes sense to
> > have them check for things that need to be done on a statement or block
> > boundary..
> >
> > >there may just be a single special op code (called trap?), which is only
> > >one byte (no args) and which breaks into a handler which can check
> > >various flags and do stuff. very reminiscent of the trap op code of many
> > >cpu's.
> >
> > Sure, we can do that too.
>
>I think something like that will be necessary.
>
>And ultimately it's going to be possible to directly manipulate the
>optree, even while a program is running, right?
Absolutely.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
