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

[Armin Rigo]

Hi Antonio,

On Mon, Mar 20, 2006 at 10:52:42AM +0100, Antonio Cuni wrote:
> The first decision I took is whether to generate IL code (to be 
> assembled with ilasm) or C# code: I choose the first mainly because C# 
> lacks the goto statement and it would be difficult to implement flow 
> control.

This makes sense, I suppose even for more reasons than just the absence
of goto's.  There are other target languages that also lack goto's, so
we might need some general way to "reverse-engineer" some structure from
the graphs, in the same way that you consider a general way to turn the
low-level operations into a more stack-machine-friendly representation.

> As you can see there are many unnecessary operations: the result of 
> 'add' is stored to v12, loaded from v12, stored in v6 and then loaded 
> from v6! The same is true for the branch instruction, which is unneeded.

I wonder how important this is at the moment.  Maybe the .NET JIT
compiler is good enough to remove all this.  How does the resulting
machine code look like?

> I think it should be fairly simple to translate from the SSA form to a 
> more "stack-friendly" form useful for stack-based machines; the question 
> is: where to put such code?
> Since it could be useful even for other backends, it would be nice to 
> put it in some place where it can be shared from several backends: one 
> option could be to write it as a backend optimization, but in this case 
> we have to introduce new low level operations for stack manipulation, 
> such as 'push', 'pop' or 'dup'.

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.

It would probably make sense to write this as a function that takes a
single block and produces a list of "complex expression" objects -- to
be defined in a custom way, instead of trying to push this into the
existing flow graph model.


A bientot,

Armin