Updated Debugging Optimized Code (markdown)

R. Bernstein 2016-01-05 02:28:57 -05:00
parent 1cd2948dcb
commit d6997fcbd1

@ -30,7 +30,7 @@ Sure, you might be puzzled about the assignment to _t1_ since you didn't write _
I maintain that even without that info, deparsing the rewritten code will show you the uses of _t1_. In sum, being able to see the rewritten code in a higher level language, rather than assembly or VM instructions, is a win.
So Although perhaps winding up in a similar place as as Zellweger, deparsing has a different point of view. The important thing here is just to describe what's there first, and then possibly unmangle or explain how the code was mangled second. In the Perl deparser which does peephole optimization, it is possible to easily undo that. But in Python some of those peephole optimizations are just covered by additional grammar rules.
So although perhaps winding up in a similar place as as Zellweger, deparsing has a different point of view. The important thing here is just to describe what's there first, and then possibly unmangle or explain how the code was mangled second. In the Perl deparser which does peephole optimization, it is possible to easily undo that. But in Python some of those peephole optimizations are just covered by additional grammar rules.
I believe that if you just present the code just the way the computer sees it, and if the programmer has reference to the original source code, the programmer would be smart enough to grok why the two are equivalent. And she might decide to rewrite her program along the lines of the transformed program if she thought that would make for a better program.