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

[holger krekel]

Hi Armin, 

On Mon, Mar 20, 2006 at 21:44 +0100, Armin Rigo wrote:
> 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:

thanks for writing out the examples.  The main work would likely 
lie in constructing such an expression.  The algorithm to
construct them from SSI would probably then be similar 
to the one generating an intermediate flow graph (for the sole
purpose of using it for gen-clr). 

> > 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()?

FWIW, that's how i thought about it.  Obviously such a CFG representation 
would not be feedable into the current machinery and transformations 
anymore, therefore only really applicable as a last step but that
is even more true for the expression based approach which excludes any
of our current transformations and would also not allow to use helper 
functions for traversal and such. 

cheers, 

    holger