[pypy-dev] CLI code generation (was: Svn account?)

[Armin Rigo]

Hi Holger,

On Mon, Mar 20, 2006 at 02:39:48PM +0100, holger krekel wrote:
> > Also useful for other back-ends would be a way to reconstruct some kind
> > of "expression tree".  For example, in Squeak, it is more efficient to
> > generate a single complex expression instead of a lot of simple
> > expressions, because of the shuffling of the local variables that the
> > latter requires.  The link with your suggestion is that these complex
> > expressions are also very stack-machine-friendly.
> 
> Interesting but isn't the IL code a bit too low level for that to 
> make full sense?

If we generated C# code, we would write the complex expression tree
verbatim as a complex expression tree in the C# source.  If, on the
other hand, we generate IL code, then we have to decompose the tree
manually in a sequence of stack operations.  That's what I meant:
expressions in trees are very stack-machine-friendly, because it's very
simple to decompose them in a list of operations in a stack machine.
For example, an expression like  g=a-((b*c)+d)  becomes:

   push a
   push b
   push c
   mul
   push d
   add
   sub
   pop g

If, on the other hand, we start from an SSI representation as in our
flow graphs, then the input looks like:

   e = b*c
   f = e+d
   g = a-f

which, if translated to a stack machine, looks like:

   push b
   push c
   mul
   pop e
   push e
   push d
   add
   pop f
   push a
   push f
   sub
   pop g

As you pointed out this is not really relevant for .NET, but for Squeak
for example, the difference above is really the difference between the
bytecodes produced by the Squeak compiler in each case, so it's
important.  Whether you generate a source expression or a list of
stack-machine opcodes is not the main question here.

> Hum, i think btw that changing/transforming pypy flow graphs
> is often not something for the lighthearted and can get quite
> involved.  But i don't see anything inherently bad with keeping
> a flow graph model for the SSI->Stack operation transformation
> at least for low level targets. 

Actually, my comment about this was guided by the fact that I didn't see
how the existing flow graph model can represent stack operations...
Antonio, did you have something more precise in mind?  A bunch of of
operations that have often no argument and/or no return value, but
implicitly operate on the stack, e.g. stack_int_mul(), stack_push(v),
v=stack_pop()?


A bientot,

Armin