Related articles |
---|
Taking an AST back into C nb_no_spam@synthcom.com (Neil Bradley) (2004-11-28) |
Re: Taking an AST back into C Martin.Ward@durham.ac.uk (Martin Ward) (2004-12-01) |
Re: Taking an AST back into C torbenm@diku.dk (2004-12-01) |
Re: Taking an AST back into C vbdis@aol.com (2004-12-01) |
Re: Taking an AST back into C vbdis@aol.com (2004-12-05) |
Re: Taking an AST back into C vbdis@aol.com (2004-12-05) |
Re: Taking an AST back into C vbdis@aol.com (2004-12-11) |
[2 later articles] |
From: | "Neil Bradley" <nb_no_spam@synthcom.com> |
Newsgroups: | comp.compilers |
Date: | 28 Nov 2004 23:25:11 -0500 |
Organization: | Posted via Supernews, http://www.supernews.com |
Keywords: | disassemble, question, comment |
Posted-Date: | 28 Nov 2004 23:25:11 EST |
I'm currently working on a code recompiler that translates binary code
back into its C equivalent. Fortunately, just about every processor
instruction can be represented as an expression (computing carry,
overflow for example).
I've created an abstract syntax tree for the binary code and am
translating it back into C, and now I'm trying to figure out when to
emit parenthesis in my expressions (so that operator precedence will
be honored).
Does anyone know of a rule or approach that would let me know when
parentheses should be emitted? As near as I can tell, it's when the
node on the right tree of the current operator has an operator that is
of differing precedence, but that just doesn't seem complete enough.
Any advice/help/hints would be greatly appreciated. Thanks!
-->Neil
[There's been a lot of work on decompilers over the years, including
one I tried that disassembled x86 object code and turned it into C.
It worked, but the results were so low-level that they were useless.
-John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.