[MUD-Dev] Re: I wanna do it OO

[Chris Gray]

[James Wilson:]

 >For those who like bytecode as an internal representation, I would like 
 >to note that using 'interpreted objects' rather than bytecode can be quite 
 >speedy. By this I mean that, for instance, a while loop can be represented
 >as 
 >
 >struct while_exp : public expression
 >{
 >	virtual rep eval (vector<rep> &stack)
 >	{
 >		while (_test->eval (stack))
 >		_action->eval (stack);
 >		return VOID_REP;
 >	}
 >....
 >private:
 >	expression *_test, *_action;
 >};
 >
 >this sort of internal representation is also really easy to integrate
 >hand-written (or automagically-generated) C/C++ code with, as opposed to
 >bytecode which doesn't have such a straightforward binding.

Nod. You can also translate the above representation (which is really
just a parse tree for the program) into byte-code readily enough. This
is what I was talking about in a previous post, about being able to
'pretty-print' the parse tree into user-selectable MUD languages.
Other than having the stack be pointed to by file-static variables
instead of being passed around as in your example, this is almost
identical to the non-byte-code interpreter in my system. My struct,
from the header file:

typedef struct {
    struct Exec *wh_condition;
    struct Exec *wh_body;
} While_t;

and the code in the parse-tree interpreter for a 'while':

	case ex_while: {
	    While_t *wh;

	    wh = ex->ex_v.ex_whilePtr;
	    while (B_TRUE) {
		runExec(wh->wh_condition, &leftValue, pType);
		if (leftValue.qv_integer == BOOLEAN_FALSE || Exiting) {
		    break;
		}
		runExec(wh->wh_body, pRes, pType);
		if (Aborting) {
		    Aborting = B_FALSE;
		    runError("execution timeout or abort");
		    Exiting = B_TRUE;
		}
	    }
	    *pType = TYPE_VOID;
	    break;
	}

Basically the same, except with a few of the inevitable extra details.
(Plus, its not C++ O-O stuff :-))
So, I can attest that what James is suggesting works quite well!

I did get additional speedup with bytecodes, however. I think the main
reason for this is that the above method uses a lot of function calls,
whereas a byte-code interpreter just loops internally. Also, MUD-language
function calls are a lot more expensive in my parse-tree interpreter
than in my byte-code interpreter, partly because of the need to do
general stuff to build the execution environment (like a stack frame)
for the called function.

--
Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA