At 11:46 AM 6/1/2001 -0700, [EMAIL PROTECTED] wrote:
>On Tue, May 29, 2001 at 06:20:40PM -0400, Dan Sugalski wrote:
> >
> > I really think we'll win if we have support for at least integers as well
> > as PMCs. There's potentially a lot of integer work that'll be generated by
> > the optimizer and, while integer opcodes might not make the interpreter
> > much faster, they'll speed up TIL and generated C code significantly since
> > they won't need to call opcodes.
>
>How much integer arithmetic does the perl interpreter actually do?
Some, though not as much as it ought as most math's done as floating point.
>Figuring out where the hot spots are in an interpreter for a general-
>purpose programming language is hard. I'd recommend against special
>cases in the registers, since it's not clear how much they'd help.
There are a few reasons to consider integer and floating point registers:
*) A good chunk of the optimizations I've been coming across seem to
benefit from integer scratch space. (Granted, generally for languages with
a different thrust than perl)
*) Code that does use it will translate more efficiently to .NET/Java
bytecode/native machine code
*) Larry's expressed a desire to let us get lower-level with perl, which'll
benefit from having integer scratch space
*) If the interpreter will support multiple source languages, they'll get a
benefit from it. (Like Python and Ruby, to name two)
It might be that there's no advantage to having them, in which case we'll
excise them and the opcodes that reference them, and that's fine. There
seems to be some advantage to it, which is why I brought them up in the
first place.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
