Nicholas --
Apologies in advance. I set out to make a short answer, but it
turned out long. Since find_op() is related to other work I want
to do/see done, discussion of it brings 'round those other thoughts,
too.
Liquefaction Guaranteed.
[snip]
> Hmm. I bet a coffee the problem is static int find_op().
> Is that implementation really the best way to provide the functionality?
I'm not surprised that find_op() is causing some distress. The "best
way" is subject to interpretation, of course. TMTOWTDI all over again.
I chose this way because whenever I started talking about op lookup
by name, cries went up about "it will be too slow!". So, I wrote the
absolutely fastest implementation I could think of. It requires only
a single scan over the op name to determine whether or not its valid,
and to return its op index in the oplib in question. I don't recall
the exact numbers, but I was getting a lookups-per-second on a par
with the ops-per-second from mops.pasm, which I think is excellent
(and probably faster than it needs to be :).
Of course, thats all irrelevant if it doesn't compile. There are two
ways out, from my perspective:
(1) Split core.ops into multiple oplibs, with the *really* core
stuff (Parrot couldn't do anything reasonable without them)
left in core.ops, and other stuff moved out to loadable oplibs.
There might even be enough heat generated by a discussion of
this we could have a nice marshmallow roast :)
(2) Switch the implementation of find_op() to something that
makes for smaller code (I almost said simpler, but I think
nested switches aren't inherently non-simple, just hard for
the compiler to keep in mind all at once when they are this
large). I had considered laying down static data structures
for a hash table, or binary search tree or something, but I
decided to make the first implementation the fastest, all
other considerations be damned.
I don't think (2) is a bad idea, but I'm actually in favor of (1),
whether or not we do (2). In fact, I've even toyed with the (doomed,
I'm sure) idea of having only one hard-coded op (wired to op zero,
but maybe still replaceable):
use_op 1, "end", "core", -1, -1, -1 # Now opcode 1 == core op 'end'
With args: OPCODE, OPNAME, OPLIB, VERMAJOR, VERMINOR, VERPATCH
Of course, assembler help would make it unnecessary to put in those
explicit op-by-op use_op's (unless you wanted to).
This approach means we don't have to even tinker with the packfile
format to get bytecode-relative optables, since they are (by
convention) built on the fly by a preamble. And, you can tinker all
you want with the opcode table at run time, too.
The standard objection to this approach is that it blows the pre-built
switching and computed goto fast cores out of the water. So, even if
this was tried, there might need to remain some way to say "go ahead
and give me the entire builtin Parrot opcode set, with whatever opcodes
they are assigned by default; I'll happily trade some flexibility for
speed". My hope is that on JITtable platforms, we'd be able to fix up
a lightning fast core on the fly out of JIT fragments, but making that
happen will require more and better minds than my own.
One of the standard benefits of this approach is that it is less
fragile as oplibs (even the core ones) evolve. Nobody cares what
index an op has within its oplib. No need for fingerprinting (yay!),
etc. As long as an op you are using (a) remains in the oplib and
(b) retains its semantics, you don't care what other ops are added,
or where. Violations of (a) blow chunks and panic, and violations
of (b) give you what the oplib owner deserves. Neither of these is
any worse than the state of things today. It will just be harder to
accidentally screw other people up when you update your WhizBang
oplib. Already compiled bytecode will continue to work without
reassembly (which is good in case the source isn't handy).
Regards,
-- Gregor
____________________________________________________________________
/ Inspiration >> Innovation >> Excellence (TM) \
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
\____________________________________________________________________/
[[EMAIL PROTECTED]]$ ping osama.taliban.af
PING osama.taliban.af (68.69.65.68) from 20.1.9.11 : 56 bytes of data.
>From 85.83.77.67: Time to live exceeded
