At 09:35 AM 5/30/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Right, but in this case we have the advantage of tailoring the instruction
>: set to the language, and given the overhead inherent in op dispatch we also
>: have an incentive to hoist opcodes up to as high a level as we can manage.
>
>We basically tried this experiment with Perl 5, and it's only a partial
>success. Yes, you end up with a Perl VM that can run Perl pretty fast,
>but it tends to complicate the mapping to other virtual machines.
>(Enough so that we still don't have a reasonable way to run Perl on a
>JVM, despite several attempts.)
I think, if we have a solid definition of the abstract machine the p-code's
targeted at, that a JIT/.NET/whatever translation should be reasonably
straightforward. Except for the regex engine, which is probably going to
drive someone (else) mad...
>I guess the real question is to what extent the world of the future will
>use interpreters, and to what extent it'll settle on JIT compiling instead.
>And that's a big enough dog that we can't wag it very easily.
If I had to bet, I'd wager that interpreter usage will increase as the
power of processors increase. How much of that usage is co-opted by JIT
versions of interpreters is something I'm not sure of.
>By the way, have you folks considered how to unify the regex opcodes
>with the normal Perl opcodes? I suspect we might want to do that.
Are you speaking of the nodes in regnode.h? I hadn't considered them as
regular perl opcodes--I figured they'd stay internal to the regex engine so
we could keep it reasonably modular.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
