How to extract the opcode and the data form the instruction
- Thread starter sciconf
- Start date
Hi,
Without knowing what processor you are speaking of, nobody can answer your question.
If you have the op codes for your processor, you can answer your own question. (hint: the processor - no matter the kind - uses hexadecimal notation. Converting to decimal is a needless complication).
Without knowing what processor you are speaking of, nobody can answer your question.
If you have the op codes for your processor, you can answer your own question. (hint: the processor - no matter the kind - uses hexadecimal notation. Converting to decimal is a needless complication).
Hi,
If you are attempting to do program disassembly, then there are some things you have to be able to establish. Like the block of memory you are trying to operate on is code and not a graphics file. I doubt that just pulling up a chunk of memory and operating on it will give you anything but junk. You have to establish some means of deermining that you are working on a valid block of code.
Then you have to establish the level of processor the code is compiled/assembled for. It's possible to have stuff that was compiled to run on a 286, for instance, and that code is a subset of, say, the 486 op code set. If you try the disassembly using the wrong op code set, the result will be garbage. Imagine operating on 16 bit code with a 32 bit only disassembler. Or the other way around.
For the purpose of disassembly, one needs several look-up tables. One for the "original" 8088 op codes, and additional ones containing the later op codes added as processors got bigger. You read in the word, and compare with the op code tables until you get a match. That's why you have to know what op code set is valid for your code. 32 bit op codes are very different from 8 bit op codes.
Because there are many ways to get it wrong, it still takes a human to go over the output of the disassembler to see if it makes any sense. I believe you also have to know a lot about the assembler/compiler to be able to write a successful disassembly routine.
If you are attempting to do program disassembly, then there are some things you have to be able to establish. Like the block of memory you are trying to operate on is code and not a graphics file. I doubt that just pulling up a chunk of memory and operating on it will give you anything but junk. You have to establish some means of deermining that you are working on a valid block of code.
Then you have to establish the level of processor the code is compiled/assembled for. It's possible to have stuff that was compiled to run on a 286, for instance, and that code is a subset of, say, the 486 op code set. If you try the disassembly using the wrong op code set, the result will be garbage. Imagine operating on 16 bit code with a 32 bit only disassembler. Or the other way around.
For the purpose of disassembly, one needs several look-up tables. One for the "original" 8088 op codes, and additional ones containing the later op codes added as processors got bigger. You read in the word, and compare with the op code tables until you get a match. That's why you have to know what op code set is valid for your code. 32 bit op codes are very different from 8 bit op codes.
Because there are many ways to get it wrong, it still takes a human to go over the output of the disassembler to see if it makes any sense. I believe you also have to know a lot about the assembler/compiler to be able to write a successful disassembly routine.
Done on x86 or disassembling x86 instruction set? These are altogether different animals...
