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 _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
