convert to high level language

[3v0]

Disassemblers do exist, but good luck with that random junk.

HP, Techtronics, and Lauterbach will all be happy to know that.

The major use for disassemblers is in debugging.
Simulators, processor emulators, login analyzers with preprocessors, ROM monitors, or JTAG like connections provide run control for the debugger (run, step, breakpoints). Code is compiled with debug options that allows the debugger to track symbols and source info (elf, dwarf, coff etc). This allows high level stepping. When doing instruction level stepping the debugger uses the disassembler to convert the machine code to opcodes. Opcodes are combined with symbolic info to provide what looks like assembler output.

You can figure out if this is the case by doing a bit of self modifying code and step through it. If it shows the opcods as compiled it is using assembler output. If not the output is from a disassembler.

MPLAB>VIEW>DISASSEMBLY_LISTING

3v0

 

[Nigel Goodwin]

You've now moved from 'de-compiler' to 'disassembler', which is a completely different thing, and easy to do - I wrote my first PIC disassembler, and the first DOS version of PICPROG, in the few days it took for a PCB to arrive from Dontronics.

De-compiling is completely different, because the information no longer exists - unless, like I said before, full debugging is ON - and the compiler has to include enough information to recreate the original code. This couldn't be done with PIC's, as you don't have enough memory!.

So basically you 'think' de-compilers exist, but you've never seen one! - and you never will, not from just the running machine code!.

 

[3v0]

You've now moved from 'de-compiler' to 'disassembler', which is a completely different thing, and easy to do - I wrote my first PIC disassembler, and the first DOS version of PICPROG, in the few days it took for a PCB to arrive from Dontronics.

I agree.
I was responding to what mramos1 said:

Disassemblers do exist, but good luck with that random junk.

The ASM to machine language translation done by an assembler is 1:1. Execpt for symbol names it is totaly reversable. There is exactly one way to translate a given ASM file and exactly one way to translate it back. Why do you objected to me saying so.

De-compiling is completely different, because the information no longer exists -

I take it you mean symbolic information no longer exists.

Yes, and even worse, the relationship between a high level language and machine code is many to one. The term decompiler is not a good name. You can feed a C decompiler any machine code for the correct target and it will generate a C program. It does not care if the original source was C, JAL, Pascal, or whatever. It will generate a C program that does what the machine language does.

unless, like I said before, full debugging is ON - and the compiler has to include enough information to recreate the original code. This couldn't be done with PIC's, as you don't have enough memory!.

Nonsense.

When you compile and run a program using embedded system tools, the symbolic information is consumed by the debugger on the workstation or PC. The target gets loaded with the machine code only. In the case of a PIC it may include a debug exec.

Are trying to put symbolic/debug info into a PIC ?

As I said earlier the decompiler does not require symbolic information, the more general case is to not use it They can be interactive, allowing the operator to choose names. They could also be constructed to take symbolic info from files.

So basically you 'think' de-compilers exist, but you've never seen one! - and you never will, not from just the running machine code!.

Yes I think decompilers exist. I spent a decade working in an embedded tools lab. Worked on compiler, assemblers, disasemblers, debuggers etc.

Google-ing (not much) resulted in 3 working examples that you have ignored. Why is that ?

3v0




From the boomerang site:

A decompiler takes as input an executable file, and attempts to create a high level, compilable, possibly even maintainable source file that does the same thing. It is therefore the opposite of a compiler, which takes a source file and makes an executable. However, a general decompiler does not attempt to reverse every action of the compiler, rather it transforms the input program repeatedly until the result is high level source code. It therefore won't recreate the original source file; probably nothing like it. It does not matter if the executable file has symbols or not, or was compiled from any particular language. (However, declarative languages like ML are not considered.)

 

[mramos1]

A disassembler is fine on smaller programs or a program written in assembler.

However a large program in a compiled language, I have seen many that I would not even bother to attempt to comment and label.

But it can be done if you have the time.

 

[Nigel Goodwin]

IYes I think decompilers exist. I spent a decade working in an embedded tools lab. Worked on compiler, assemblers, disasemblers, debuggers etc.

I notice you didn't include de-compilers in that list?.

Google-ing (not much) resulted in 3 working examples that you have ignored. Why is that ?

Because they are too limited and of no relevence, they are basically for PC (or at least Intel) code - this has no bearing whatsoever on PIC programs.

 

[3v0]

Everything was covered in my first and last post.

3v0