[SOLVED] Some 8086 doubts..........

[DEV123]

Hi friends,

I have some fundamental doubts.

1) 8086 instruction format allots first 6 bits for opcode. But how 117 total instructions can be generated from 2^6 = 64 combinations. Is it bcoz some instructions are same like JZ,JE etc.

2) How do processor knows if the data stored suppose in AX in unsigned binary / signed number. Is it through checking flag bits.

-Devanand T

 

[DEV123]

1. I went through the datasheet here:

http://datasheets.chipdb.org/Intel/x86/808x/datashts/8086/231455-005.pdf

Some instructions have same opcode encoding. Best example is in pg. 28 for the shift/rotate instructions: they all have the same opcode value of 110100, but the 3-bit 'reg' field is used to distinguish between various operations. Again, there are logical equivalences with jump instructions (like JNGE == JL or JNLE == JG), this brings down the number of real instructions. In general. the opcode field only specifies the *class* of the instruction, and not necessarily the entire instruction itself.


2. The processor does not care about signed/unsigned numbers, it simply treats everything as unsigned and performs operations. This is usually the case with most processors. Signedness of a number is the concern of the programmer; it is only an interpretation.

Can you tell what this bit pattern 1010_1010 represents? The answer depends on how *you* treat it. If treated as unsigned, it represents the number 170, but as signed, it represents the number -84. If this number was generated due to some arithmetic operation, the appropriate flags will always be set (in this case, the sign flag will be set, assuming an 8-bit processor). It it upto the programmer to decide if the sign flag has any meaning in his calculations or not: if he is dealing with signed numbers, the answer is interpreted as -84, else as 170. If this value is to be printed on a screen, the printing routine will also need to know how to treat it. This also explains why there are different specifiers for signed (%d) and unsigned (%u) for printf.

-- Answer from my friend Sai Krishna

- - - Updated - - -

1. I went through the datasheet here:

http://datasheets.chipdb.org/Intel/x86/808x/datashts/8086/231455-005.pdf

Some instructions have same opcode encoding. Best example is in pg. 28 for the shift/rotate instructions: they all have the same opcode value of 110100, but the 3-bit 'reg' field is used to distinguish between various operations. Again, there are logical equivalences with jump instructions (like JNGE == JL or JNLE == JG), this brings down the number of real instructions. In general. the opcode field only specifies the *class* of the instruction, and not necessarily the entire instruction itself.


2. The processor does not care about signed/unsigned numbers, it simply treats everything as unsigned and performs operations. This is usually the case with most processors. Signedness of a number is the concern of the programmer; it is only an interpretation.

Can you tell what this bit pattern 1010_1010 represents? The answer depends on how *you* treat it. If treated as unsigned, it represents the number 170, but as signed, it represents the number -84. If this number was generated due to some arithmetic operation, the appropriate flags will always be set (in this case, the sign flag will be set, assuming an 8-bit processor). It it upto the programmer to decide if the sign flag has any meaning in his calculations or not: if he is dealing with signed numbers, the answer is interpreted as -84, else as 170. If this value is to be printed on a screen, the printing routine will also need to know how to treat it. This also explains why there are different specifiers for signed (%d) and unsigned (%u) for printf.

-- Answer from my friend Sai Krishna