At 07:40 AM 6/5/2001 -0700, Dave Storrs wrote:
>On Tue, 5 Jun 2001, Dave Mitchell wrote:
>
> > dispatch loop. I'd much rather have a 'regex start' opcode which
> > calls a separate dispath loop function, and which then interprets any
> > further ops in the bytestream as regex ops. That way we double the number
> > of 8-bit ops, and can have all the regex-specific state variables (s, send
> > etc in the earlier example) and logic separated out.
>
> This is an interesting idea...could we use this more generally to
>multiply our number of opcodes? Basically, you have one set of opcodes
>for (e.g.) string parsing, one set for math, etc, all of which have the
>same value. Then you have a set of opcodes that tells the interpreter
>which opcode table to look in.
Nah, that's too much work. We just allow folks to define their own opcode
functions and assign each a lexically unique number, and dispatch to the
function as appropriate.
Adding and overriding opcodes is definitely in the cards, though in most
cases it'll probably be an opcode version of a function call, since
machine-level stuff would also require telling the compiler how to emit
those opcodes. (Which folks writing python/ruby/rebol/cobol/fortran front
ends for the interpreter might do)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
