Simon --
> > I've continued to play with the DO_OP simplification patch I posted
> > before. I've removed the op info stuff from the op func struct per
> > suggestions from Dan.
>
> Very nice,
Thanks!
> but can I remind you and everyone else that we're trying
> to get it working before we get it pretty? Premature optimization and
> all that.
I agree. The only reason I did all the performance investigation was
that my prior posts that messed with the inner loop were critiqued
on that basis (remember op tracing?). So the only point in doing that
was to assure any performance-minded folks that in the course of
doing a little refactoring I hadn't screwed up performance.
Having said that, I think the new DO_OP definition:
#define DO_OP(PC,INTERP) PC=((INTERP->opcode_funcs)[*PC])(PC,INTERP);
and calling sequence:
opcode_t * code_start = code;
while (code >= code_start && code < (code_start + code_size)
&& *code) { DO_OP(code, interpreter); }
return code;
are much more readable that the old DO_OP definition:
#define DO_OP(w,x,y,z) do { \\
x = (void *)z->opcode_funcs; \\
y = (opcode_t* (*)())x[*w]; \\
w = (y)(w,z); \\
} while (0);
and calling sequence:
opcode_t *(*func)();
void **temp;
opcode_t *code_start;
code_start = code;
while (code >= code_start && code < (code_start + code_size)
&& *code) { DO_OP(code, temp, func, interpreter); }
return code;
Note that it would be easy to get rid of the extra addition within
the while condition (which was a point I believe you didn't like
about the current implementation). In fact, I think I posted
example code using one of the interpreter flag bits for 'safe'.
The 'unsafe' version would look something like this:
while (*code) { DO_OP(code, interpreter); }
return code;
which is probably right up everybody's alley in terms of readability.
And, as Dan pointed out, a pretty-safe execution mode could be had by
putting some code in the branch ops to make sure they don't branch
out of the code block (block bounds presumably available via the
interpreter pointer).
And, as I've said before, with either end (op zero) or err (op one?)
tacked on to the end of every loaded bytecode stream N + 1 times,
where N is the maximum number of op arguments, we will know that we
can't segfault due to falling off the end or having an op with out
its args at the end of the bytecode stream. This is probably cheap
enough to be enabled all the time, and not too hard to implement
(but most definitely something to be done not only after 0.0.2, but
probably after anything accepted from this patch is applied, too).
Having a controlled exception-reporting mechanism instead of segfaulting
will be nice for embedding within other applications as a library.
Other times, we can take the error and turn it into noisy death
quite easily ourselves.
> If we get it working everywhere we want it, then we do a 0.0.2 release,
> *THEN* we can arse about with clever optimizations.
Agreed, but note that my main point isn't optimization. Its readability
and factoring for code sharing between the interpreter and other tools.
Committing this stuff can wait until the 0.0.2 release is done, but
I imagine there are some folks who'd like to try it out, and I'd
like to get their feedback (specifically on portability) so that I
can post and promote a known-good version of the patch once we're
ready for the next cycle.
BTW, do we have a short (or long) list of gotta-have-resolved-
before-0.0.2 issues? Everything seems to run pretty well here
modulo some recent assembler problems (I just commented out the
offending lines locally so I could work on other stuff).
BTW2, I *would* like to get my Jako changes and the one-line
assembler patch that allows end-of-line comments in to 0.0.2. I
don't think the current jakoc does enough to be very interesting
to folks, but the new one probably does just enough right to get
people's ideas flowing. I'll leave it up to you...
Regards,
-- Gregor
_____________________________________________________________________
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_____________________________________________________________________/
