Can we convert HEX code to C code? Is there any tools avaliable?
with thanks, Karthik
"...to C code written by an ASM programmer."
Being a programmer of embedded systems for more years than I care to mention, I find it strange that a distinction is made.
I would not employ someone for the position of embedded programmer if they wanted to classify themself as specifically a C programmer or specifically an ASM programmer.
"Other than the "science project" of it what would be a real use for it? It seems like the hamburger cow, interesting, but now what do you do with it?"
I have seen references to this concept outside the "science project" world, as an alternative to use of a free-standing simulator of the original processor for use on many different target architectures. The conversion basically results in a simulator being integrated with the found machine code.
One problem with simulating a processor is that a very large percentage of the time is spent always making sure that the simulator produces identical processor flags since the simulator does not know if any of the following instructions will care about the carry, parity, ... By flow-analyzing the machine instructions, you can identify flags that are not relevant and in some situations perform a native a+b instead of a simulate_add(a,b).
As I mentioned, this concept does exist in the form of just-in-time compilation of partial code blocks in a number of simulators. This is for example how better x86 simulators manages to get a reasonable speed when running Win32 applications on non-x86 processor.
But a simulator with just-in-time compilation has one big portability problem, since such a simulator is bound to both host and target. It must know the instructions it is simulating, and it must know the instructions it should generate.
If analyzing and generating a sequence of C source lines instead, can produce an output file that can be compiled and run on more than one host machine. You can get an application that runs significantly faster than if 100% simulated. That the binary produced from compiling the generated C code and linking with the support library will be significantly larger than the original binary doesn't often matter since you are probably moving the application to a way bigger machine.
But the big thing to note, is that the produced C code is not the C code you or I could use as a basis for maintaining the original application. It is just low-level "intermediate" data. A huge number of goto and a very small (possibly zero) amount of detected higher-end constructs such as loop, switch statements etc.
Converting assembler to a "real" C program is still research class, and a type of problem that shouldn't be spent time on other than possibly as a stepping stone (input data) for the general development of new pattern-matching and search algorithms.