Decompilers exist for many different architectures and languages. However, the output is likely to be worse code than the input. You'd learn more just doing the conversion the old-fashioned way: reading the asm and writing the corresponding C yourself.
Among other things, symbol names and some other information is lost. The output will be very literal and probably not particularly easy to read.
It's not IN a compiler. It's a separate program that you feed the asm to and you get out a very confusing compiler version. The output generally does not use headers and includes so you get out ALL the code needed to assemble the asm.
It's most confusing and like Torben said it would be much easier to learn ASM.
I've read many 'asm to C' attempts to decompile in a sensible symbolism, all of them are at best half-assed. They usually use simple proper noun replacement to try
to help native understanding of the converted code, and it's always bad.
Bob is my uncle, my uncle is 3.1415926 positive times in relation to itself and his father is 3 less than his mother is 1 more than her daughters last mood change.
If you just want to use the ASM code in a C environment use an inline ASM argument, most C copilers support this if the ASM memory/code structure is known.
Thats tough to do. There are so many assembly combinations out there for a set of C instructions, that it makes this very difficult. If you want it done right, you're best off doing it yourself.
It's not IN a compiler. It's a separate program that you feed the asm to and you get out a very confusing compiler version. The output generally does not use headers and includes so you get out ALL the code needed to assemble the asm.
Really all program languages are built from machine code which directly correlates to the assembly language mnemonics. You would have to reverse engineer it yourself. I suggest getting "WinDbg.exe".
I'm with Nigel. While decompilers exist and while there are examples of compiler/decompiler packages, they are not the norm and the statement that "it probably came with your compiler and assembler" is not true.
Unless of course you feel like providing some links to back up your statement. It's not our job to defend your position. If you can't be bothered to, why should anyone else?
Basic code to ASM or De-ASM is integral to any compiler that understands it's own hardware architecture, things like Java based programming or higher end languages are exempt of course.
Basic code to ASM or De-ASM is integral to any compiler that understands it's own hardware architecture, things like Java based programming or higher end languages are exempt of course.
While I'm aware of quite a number of third-party decompilers, I'm not familiar with any common compilers which come with an asm-to-<insert original language here> decompiler, although most of the compilers I've used do produce (or can be configured to produce) assembler output as an interim step in the compilation process.
Disassemblers are a different topic and of course are required for use in interactive debuggers. They generally do not produce code in the original high-level language, though.
I'm with Nigel. While decompilers exist and while there are examples of compiler/decompiler packages, they are not the norm and the statement that "it probably came with your compiler and assembler" is not true.
Unless of course you feel like providing some links to back up your statement. It's not our job to defend your position. If you can't be bothered to, why should anyone else?
Torben
I don't require anyone to defend my statement. There are decompilers around that is in evidence from other posters and Google and In some of the original C++ releases a decompiler came with it. I have no knowledge of more recent versions so cannot comment further.