There is a good article in "The Firmware Handbook" (Jack Gansel ed. Newnes 2004) called "Understanding Your C Compiler," written by Jakob Engblom (IAR compiler developer) which points out the steps a compiler takes to make a machine executable. If you read that, you will begin to understand why a 'decompiler' is not practical.
There is a good article in "The Firmware Handbook" (Jack Gansel ed. Newnes 2004) called "Understanding Your C Compiler," written by Jakob Engblom (IAR compiler developer) which points out the steps a compiler takes to make a machine executable. If you read that, you will begin to understand why a 'decompiler' is not practical.
Not sure who you're talking to here, but decompilers are indeed practical and there are lots of them out there.
Now, a decompiler which produces readable output and scales well--that's another question entirely. And a round-trip decompiler (where you actually get back the original source code) would be like unburning paper unless special provisions were made to support it in the original compiler.
Not sure who you're talking to here, but decompilers are indeed practical and there are lots of them out there.
Now, a decompiler which produces readable output and scales well--that's another question entirely. And a round-trip decompiler (where you actually get back the original source code) would be like unburning paper unless special provisions were made to support it in the original compiler.
Yeah, that's pretty much been my experience too--although I've done more with disassemblers than decompilers. Disassemblers have the advantage of actually being useful.