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).
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.
> 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?
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
