Re: Handling the Perl VM's "list" op with Kawa IR

["Bradley M. Kuhn" <bkuhn at ebb dot org>]

Per, please first let me thank you for taking the time to assist me!  I
apreciate it a lot.

Per Bothner <per@bothner.com> wrote:

>  Compare the Java expression stack.  To compile Java bytecodes you have
> two options: (1) Compile to a environment that preserves the stack, and
> does stack operations at run-time; or (2) compile away the stack, by
> simulating pushes and pops at compile-time.  Better JVM compilers do (2).
> So the question is: Can you do something similar with the Perl temporary
> array - an dif so, should you?  Have people worked on compiling Perl IR to
> C code?  If so, what did they do?
 
Sadly, I am mostly working in unchartered territory.  Two C back-ends have
been attempted, but they mostly consisted of dumping the parse tree to C
code and linking back to libperl.so to carry out the operations.  So, of
course they preserved the stack, because they weren't attempting any
intelligent compilation.

The back end compiler modules for Perl were added as an after-thought, and
it shows.  To my knowledge, no one has really been able to get them to do
anything useful.

(Indeed, I have been struggling for two years off and on trying to get them
to do something useful, and this integration with Kawa is the closest I am
coming to something cool.  ;)

> If the temporary array is predictable way, only within a given statement,
> and you know when "marks" are pushed/popped, then presumably you can
> compile away the temporary array.

The temporary array is completely predictable.  AFAIK, it's use is by
LISTOPs only.  If a LISTOP uses the temporary array, it will do a "pushmark"
operation, and on the post-processing, it will find its mark and do
something with the contents from the mark to the end.

So, the temp. array's operation is completely predictable, and I do believe
it can be compiled away with careful compile-time analysis.

> I assume you can, since there is nothing in the Perl *semantics* that uses
> this temporary array - right?

That is correct.  By the time I get to where I am at in the backend, the
semantics of list and scalar context have been worked out.  In fact, LISTOPs
were generated because semantically, a list context was needed.  The Perl
temporary array is the method used in the Perl VM for implementing list
context.

> Of course it doesn't follow that you *should* compile away the temporary
> array, even if you can.  The reason is that if this array (stack) persists
> for a while, you may save on object allocation.

I don't think there is real savings here on object allocation.  The
temporary array is always cleared at the end of each statement.
 
> An idea:

[...]

> This is pretty dense, I admit.  I've left a bit vague the actual calling
> convention to be used at run-time.  For that, I suggest taking a look at
> the Consumer and ConsumeProc classes in gnu.kawa.util.

I followed most of your example, but it seemed your idea was centered around
trying to preserve the temporary array.

Based on your comments before "An idea:", I am pretty much convinced that
"compiling away" the temporary array is the right approach.  I hope that
decision doesn't come back to bite me, of course.  ;)

-- 
Bradley M. Kuhn  -  http://www.ebb.org/bkuhn

PGP signature