>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:

  >> well, i am sorta pushing for more work to be done on actually
  >> implementing some early core stuff. i proposed work on the event system
  >> even as a learning project to get a portable event system up in perl5.

  DS> Cool--so... got that Async I/O and Event PDD done? :)

when my wife's broken leg heals, i may have some tuits. 

  >> >> i think that is best done with inserting special op codes when enabled
  >> >> by a profiling or debug flag.
  >> 
  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.

  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.

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.

uri

-- 
Uri Guttman  ---------  [EMAIL PROTECTED]  ----------  http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info:     http://www.sysarch.com/perl/OOP_class.html

Reply via email to