At 06:54 PM 10/30/2001 -0600, Kevin Huber wrote:
>The code density is one thing that surprised me. Even with 4 byte
>opcodes and arguments, pbc is very reasonable.
Code density's the place where perl's always had a big win. Either an
interpreter's got a very limited set of ops (to fit in a byte, usually) or
the designers get all arty and prattle on about cleanliness, simplicity,
and elegance. Perl's usually taken the engineering approach. If I can
collapse a dozen ops into one and shave off 11 op dispatches, it works for me.
>I don't think it will be possible to get within an order of
>magnitude of C or Java+JIT without a JIT or some precompilation to
>native code, though I would be interested to see how a better dispatch
>or alternate register file scheme works.
Different dispatch makes a huge difference. Either a big switch or a
computed goto (depending on the capabilities of your compiler and your
platform's proclivities) get a big win in most cases. I'm not sure about an
alternate register file or a stack scheme instead of a register scheme, but
we can experiment some when we have more code to work with.
>Writing a VM from the bottom up
>sounds like a great opportunity to make optimization
>easier, rather than, say, trying to make a Java VM fast where
>you're stuck with a legacy virtual machine architecture.
The moment you release version 1.0.1, you're already in legacy territory.
:) The JVM has different design goals than we do, as far as I can tell, and
has a different sort of language targetting it. (Static typing makes some
compiler things a lot easier) That's OK, I'll be happy if we blow the doors
off it when ruinning real code. :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
