Dan Sugalski wrote:
> At 01:52 PM 8/2/00 -0400, Ken Fox wrote:
> >Dan Sugalski wrote:
> > > I wanted to do this not so much to reduce the size of the core (They're not
> > > *that* much code) as to reduce the number of opcodes being used. I really,
> > > *really* want to trim down the opcode list.
> >
> >If we reduce the number of opcodes, we need to consider the performance
> >impact -- perl ops run a *lot* of machine instructions and reducing the
> >number of them might mean more ops have to run in order to accomplish the
> >same thing as before.
> I'm not talking about tossing sassign or the like. I'm talking about fork,
> wait, log, localtime... things that don't get called enough to be an
> opcode. I mean, if we doubled the amount of time that localtime took,
> would it really matter?
I have to agree here. I support simplifying the opcodes, both by reducing
the number and reducing the number of options per opcode (perhaps by making
other opcodes---that's a trade-off of course).
One of the hardest parts of porting Perl to the JVM is handling every last
opcode and generating equivalents for it for the other architecture. If the
IR of Perl were simplified, this would allow for easier ports.
Of course, the IR need not be the same as the VM. In fact, if we decouple
the two, compiler writers could focus on the IR and ignore the VM. In
perl5, these are so intimately coupled, you cannot work with one without the
other.
I don't have any clear ideas yet on how they might be separated yet, but I
might have an RFC on that forthcoming in the months to come.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
