At 03:30 PM 7/9/2001 -0400, Uri Guttman wrote:
> >>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> PJ> Done by what? Adding opcodes at all conceivable positions could
> PJ> be unnecessarily expensive for most applications, and you're bound
> PJ> to miss something that someone wants. I would imagine this is
> PJ> best done on a case by case basis, but maybe you were thinking
> PJ> that way too.
>
>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.
> DS> Actually you don't do either. What you do is piggyback on top of
> opcodes
> DS> that already are in the stream.
>
> DS> There *will* be "begin scope", "begin loop", "End scope", and "End
> loop"
> DS> opcodes as well as an "end statement" opcode and possibly a "begin
> DS> statement" opcode. (Though I'm less sure of that) There is and will
> DS> probably always be some sort of setup or teardown needed when lexical
> DS> scopes begin or end, as well as when statements end. The "end of X"
> DS> functionality will be done by piggybacking on these opcodes.
>
> DS> Whether the opcodes themselves check flags, or we just override
> DS> the opcode functions when needed (flags sound better since we can
> DS> lexically scope those a lot easier, with less impact on threads
> DS> and such) is up in the air.
>
>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).
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.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
