At 04:34 PM 7/10/2002 -0600, Luke Palmer wrote:
>On Wed, 10 Jul 2002, Melvin Smith wrote:
>
> > At 02:13 PM 7/10/2002 -0700, John Porter wrote:
> >
> > >Dan Sugalski wrote:
> > > > John Porter wrote:
> > > > > but what about non-PMC variables?
> > > >
> > > > Generally speaking, there aren't any. Everything else (in this case
> > > > the buffer/string things) is for internal use only. Languages aren't
> > > > supposed to expose strings directly.
> > >
> > >Languages are only supposed to expose PMCs?
> > >Not ints, nums, strs?
> > >Why have them if Perl can't see them?
> >
> > Since Perl vars type-morph themselves, Perl will use PMC types everywhere
> > that there is an exposed interface. Internally you could use an I/S/N
> register.
> >
> > I see no reason why
> >
> > foreach my $i (@nums) {
> > ...
> > }
> >
> > should not use an Ix reg for $i, but maybe $i isn't an int at all, or @nums
> > is actually a mixed list. Even if we did know that @nums was all integers,
> > as soon as we see:
> >
> > %MY{'$i'}, or we find an eval{}, $i must escape the register and we lose
> > the optimization.
>
>So we don't see them. %MY is so ugly nobody will want to use it. And as
So take it out and inform Larry. :)
>for eval{}, that's actually eval "". try{} will not pose a problem. Keep
>in mind that eval "" isn't that common either. Also if you're compiling
>some code every iteration, an integer optimization won't help out that
>much.
Thanks for the syntax correction...
I was referring to the above situation where a lexical might be optimized
away without being stored in a pad (for %MY).
Granted, I never said it was used often, just that it may kill optimizations.
I may also be too paranoid. I really don't care for %MY either, but it
isn't my language.
>And we do know whether @nums are all integers, if people program well.
>Arrays can be typed, too.
I don't know enough about this to comment.
I do know that PMC (Px register) usage gives up a lot of
performance to Ix/Sx/Nx regs, especially on JIT, and we should optimize
in every possible case.
-Melvin
