On Oct 07, "Bryan C. Warnock" <[EMAIL PROTECTED]> took up a keyboard and banged out
> On Sunday 07 October 2001 10:51 pm, Michael Fischer wrote:
> >
> > Questions, comments, criticisms?
>
> It looks like you're implementing this as a full, solitary switch.
>
> while (*pc) {
> switch (*pc) {
> }
> }
Right, as per Simon and Dan's original suggestions to me.
>
> I don't see (on simple inspection) a default case, which implies that all
> functions would be in the switch. There's two problems with that. First,
> you can't then swap out (or add) opcode functions, which compilation units
> need to do. They're all fixed, unless you handle opcode differentiation
> within each case. (And there some other problems associated with that, too,
> but they're secondary.)
Um, yeah, I left out the issue of default, as I had no idea what to do
with it ( fprintf(stderr, "Hey, non-opcode!"); exit( EXIT_FAILURE ); )???
Anyway, suggestions from the list welcome on that point.
It is generated as a pass over basic_opcodes.ops, just as the function
definitions in basic_opcodes.c are done. I figured the philosophy was
"Don't hack the output, hack the template" if you want to change the
generated file. What swapping of opcodes do you imagine? I wouldn't have
thought that user code gets to muck with the asm offerings available.
> Second, the switch will undoubtedly grow too large
> to be efficient. A full switch with as few as 512 branches already shows
> signs of performance degradation. [1] Thirdly, any function calls that you
> then *do* have to make, come at the expense of the switching branch, on top
> of normal function call overhead.
How many asm opcodes do you imagine we'll have? I'm hardly expert here,
but I have a hard time believing we're going to have anything like 512.
Much of the remaining flexibility would be done in the vtable code.
Unless of course, _every_ new vtable function has to be re-written as
a single opcode... oh dear ... but now I'm getting confused.
As I understand it, all the function calls get inlined into the loop,
so what ones are going to be called inside it?
Sorry if I'm being dim and missing issues, I just wanted to get
this thing done, and I followed instructions. Perhaps needs/designs have
changed since instructions were given.
>
> [1] Pre-Parrot testing at
> http://members.home.net/bcwarno/Perl6/spool/opcode_test_results.txt
>
> [2] The code for my last set of benchmarks at
> http://members.home.net/bcwarno/Perl6/spool/interpreter.c
Um, the latter's include file looks an awful lot like the switch
my patch generates. How does it work better? Not trying to be
antagonistic, I just don't see how it is any different/faster.
Clues welcomed.
Cheers.
Michael
--
Michael Fischer 7.5 million years to run
[EMAIL PROTECTED] printf "%d", 0x2a;
-- deep thought
