On Tuesday 09 October 2001 12:05 pm, Paolo Molaro wrote:
> > It improved the speed of non-optimized code, because you didn't jump to
> > the end of the switch simply to jump back to the loop conditional. But
> > I didn't see any additional improvements with optimized code, because
> > the optimizers take care of that for you. (Well, really, they put
> > another copy of the while condition at the bottom.)
>
> Yes, that was basically the same mistake I did at first when testing
> the goto label stuff, little or no improvement. But the 'right' way to do
> it is to use the goto label construct not only instead of switch(), but
> also instead of 'break;'. Oh, and the address array needs to be
> declared const and static, too.
>
> const static void * goto_map[] = {&&OP1_LABEL, &&OP2_LABEL, ...};
>
> ...
> while (1) {
> goto *goto_map [*ip]; // switch (*ip)
> OP1_LABEL:
> do_stuff ();
> update_ip ();
> goto *goto_map [*ip]; // break;
> OP2_LABEL:
> do_other_stuff ();
> update_ip ();
> goto *goto_map [*ip]; // break;
> ...
> }
Ooh, I like that. I'll have to experiment.
> > I've got three different opcode loops so far for Parrot.
> > (Linux(x86)/gcc, Solaris(SPARC)/Forte, and Solaris(SPARC)/gcc). I've
> > tried most every combination I can think of (am still working off the
> > last couple, as a matter of fact). (Particularly ever since I received
> > the inexplicable slowdown adding a default case.) Take nothing for
> > granted, and try it all. I've posted some of my more ridiculous
> > failures, and have posted what I have found to be my best numbers.
> > Anyone is free to come up with a better, faster solution that meets the
> > requirements.
>
> Thanks for your efforts, hard numbers are always better than talk! :-)
> I was just trying to offer the experience I gathered working on similar
> issues, hoping it can be useful. And yes, I was suggesting to change
> a bit the requirements (not of the language, but of the current VM design)
> more than proposing an implementation of it.
That would be up to Dan, then. I may pitch small tweaks to the design (like
reserving a set of opcodes strictly for as core internal), but I'm not
confident enough to do more than that.
(It's like Grandpa's Five Iron. (You replace the head, the shaft, and the
grip, and still call it Grandpa's Five Iron.))
We are going to need to come up with a better strategy than a DO_OP macro,
though.
--
Bryan C. Warnock
[EMAIL PROTECTED]
