At 11:44 AM 7/6/2001 -0500, David M. Lloyd wrote:
>On Fri, 6 Jul 2001, Dan Sugalski wrote:
>
> > At 01:26 PM 7/5/2001 -0500, David M. Lloyd wrote:
> >
> > >It would be nice to be able to tell the interpreter to call a user-defined
> > >C function between opcodes. This could make it easier to implement
> > >debuggers, profilers, etc. as well as providing a method of safely using
> > >asynchronous callbacks that certain C libraries like to use.
> >
> > Yup, that's how the event handling stuff will be handled.
> >
> > >Of course, if you guys already have a better scheme in mind, don't let me
> > >stop you. :-)
> >
> > You've pretty much got it. The flag-checking will be hardwired, but
> > there's no reason that the function called can't be user-defined.
> > Being able to install an arbitrary number of user-defined inter-opcode
> > (and inter-statement) functions seems to make sense, and I don't see
> > it as incurring any extra costs, so... (As long as you don't mind that
> > it doesn't necessarily happen in a truly compiled version of your
> > program)
>
>Why wouldn't it get included in a compiled version? Optimization
>issues? It seems to me that if I write a module that does profiling or
>something, and the user includes it in their compile, they are saying, "I
>understand the costs involved in polling for a callback between logical
>operations, and I'm willing to accept those costs".
When I said "truly compiled" I meant down to C, or via a TIL scheme, or
straight to machine code. Things that go to bytecode will still be run
through the opcode loop, which means that all the standard inter-op stuff
will be available.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
