If you want to disassemble a piece of code in order to reuse it elsewhere, well, unless you're equipped, mentally at least, to understand, fully, what it is doing, warts and all (and it will have some), you will probably get into more trouble than it's worth. If, however, you have a very good understanding of the hardware environment and functional goals for and with which it was written, you may be able to derive some benefit from it.

The key is that, once, disassembled, you can take the code and add the missing comments, whereupon you may actually be able to understand its function more fully.

Consider, for example, a case in which there's a pretty large piece of firmware, say, 8KB in size. That will probably produce a disassembly listing on the order of 32 KB in size, since there are absolutely no comments. In addition, there will ideally be a symbol cross-reference (and you'll have to assign meaningful mnemonics to the numeric symbol names the disassembler has generated), and then you'll have to identify the subroutines or macros that the original code contained for performing obviously essential functions, e.g serial I/O, etc. Then you'll have to learn a considerable amount about the coding style of the author of the code, which becomes really tricky of there were multiple coders, provided it's reasonably consistent and sensible. Things like calling a single subroutine to perform character I/O will become apparent, as will a string-output or input procedure ... if you're diligent ... and lucky.

It all depends on what your goals are.

After all is said and done, there's no substitute for doing the work yourself. You can, and perhaps will, do it better.

A classic way in which to benefit from a disassembler is when there's a pretty large and quite useful piece of work that you feel needs a small modification to be what you wanted, e.g. a debug monitor for which you want to use an external UART rather than the internal one that the original piece of code used, but for which the original author was no longer available, nor was source code. In such a case it just might be sufficiently straightforward to isolate the character I/O routines used by the original coder, and substitute ones that you write yourself to do things the way you desire.

If you feel you need to make LARGE changes, you're probably better off struggling to understand what the code does, but to write your own version, as you'll then understand what's going on. It's seldom worth trying to get into someone else's head when you can do the work yourself.

If you can't do the work yourself, you probably can't "hack" someone else's code to make it function as your own, so don't waste your time.

A disassembler is a too, and not too difficult a tool. Its output is of limited usefulness, requiring lots of your own effort to make it useful to you. Any disassembler that is worth its salt, so to speak, is one that produces formatted output code with correct mnemonics, line numbers, and a complete cross-reference and symbol table. Most of the time there are more symbols in the disassembled output than what the original coder used, but that's up to you to work out. I'm sure you can imagine that it's a lot of work to get from the raw disassembler output to something you can read and understand.

[edit]One more thing ... If you expect to disassemble intelligible code from the output of a compiler ... well ... guess again.[/edit]

RE