[pypy-dev] CLI code generation (was: Svn account?)
arigo at tunes.org
Mon Mar 20 14:21:19 CET 2006
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
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.
More information about the Pypy-dev