OSDev.org

Hello all

I am rather new when it comes to programming as low level as this. I have written a few emulators in the past, but would like to understand the deep things a bit more.

One thing I have always wondered, is how people know the actual Hex values of the CPU opcodes. What I mean by this is, what indicates that the MOV command is Hex value 0x.....?

I was looking at the Intel manual the other day, and it has a big list of the opcodes it uses, but I did not see any Hex values.

I am completely wrong in my thinking here, or am I simply missing something?

Thank you all very much for your help,

Richard Hughes

the intel manuals are huge, but if you dig through enough you will find some info explaining how the majority of opcodes actually have their hex code determined by several binary fields.

one of the fields determines something like "this is an AND instruction" or "this is an OR" instruction. another bitfield will indicate the source and destination operands involved, for example that it operates on a full word or only a byte (this is actually termined bit 0 of many 8086 opcodes), and another bitfield indicates "source operand is a general register, destination operand is a memory location" and so forth.

it gets pretty complex, because not all instructions will fall into these rules perfectly. some were seemingly assigned randomly or wherever it coudl be fit in.

take a look at an 8086 opcode hex map and you will see some patterns. some of the most obvious patterns are the opcodes in the range from 00h to 3Fh. these cover many of the AND, OR, ADC, SBB, AND, SUB, XOR, and CMP instructions. you will see more patterns if you look around the map a bit more.

a large number of 8086 isntructions actually have a second byte that is an extension of the opcode that provides specific addressing mode information. it's called the ModRegRM byte, and it has 3 bitfields. one is called the "mode" (it is the highest 2 bits) and it determines what the other 2 fields actually mean. this is from a doc i put together when i started writing my PC emulator, the second and third pages explain this byte:

http://rubbermallet.org/8086%20notes.pdf


the primary (first) opcode byte in front of the ModRegRM byte would indicate which of the "reg" and "RM" fields are the source and which is the destination.

Oh really. So it is just a case of Googling or reading through manuals to see each opcode's hex value then? (This makes me feel less bad about copying the hex values from other code then...)

yeah, you'll get the best info from the intel manuals but this pdf gives a good general explanation:

http://umcs.maine.edu/~cmeadow/courses/ ... format.pdf

berkus wrote:

rhughes wrote:I have written a few emulators in the past, but would like to understand the deep things a bit more.

How have you managed to write emulators without knowing how to interpret that stream of bytes?

And yes, the opcodes are in the processor/architecture manual.

it sounds like he had a list of the instructions and what they are, but now he wants to understand why those hex numbers work out to be what they are.

berkus wrote:How have you managed to write emulators without knowing how to interpret that stream of bytes?

I have found the Hex code to opcode map in either other people's code or web pages.

I was just wondering how they themselves found out.

Simple, thanks for your help guys.

PS, The speed of the responses here is amazing. Thanks again!

Just my favourite piece of documentation about opcodes: ftp://93.175.16.134/Opcode.txt
This is very old but octal structure of opcodes is a very common thing and it's actual even now.

Nable wrote:Just my favourite piece of documentation about opcodes: ftp://93.175.16.134/Opcode.txt
This is very old but octal structure of opcodes is a very common thing and it's actual even now.

that is an awesome reference, nice link.