 The "Go" tools
The GoAsm manual
understand ....
finite, negative, signed and two's complement numbers
by Jeremy Gordon -
This file is intended for those interested in 32 bit assembler
programming, in particular for Windows.
Outside the world of computers, numbers are regarded as having the
capacity to be infinite in the
sense that if you have a number like 345,000,000 you can just keep adding
more zeroes to it and it will get larger and larger.
Computer numbers are necessarily different because the size of the chunk
of data being worked with is finite. For example a byte cannot hold a number
larger than 255. If in a byte instruction, you add 1 to 255, the number
in the byte becomes zero. In practice in this situation the instruction
causes the carry flag to be set to 1 to show that
the new number was too large for the data size being used. You would
then know that the result was not zero, but actually 256.
Because the data size is finite, it is possible to regard the data
as having two values at any one time, a positive value and a negative
value.
Let me explain. Suppose you have a byte with all its bits set
to 1. Then you might say the byte contains the number 0FFh (or 255
decimal). But this can also be regarded as the number -1 (that is,
one less than the condition in which the number is too large for the data
size being used). You can prove that it is correct to regard the number
as being -1 because if you add +1 to -1 the result is zero, which is
correct for the data size concerned (although there is a carry).
In programmer's jargon, regarding the chunk of data as possibly
holding a negative number means that the number is referred to as a
"signed number". Whether or not the number is negative depends on the
most significant (leftmost) bit in the chunk of data, which is called
the "sign bit". If the data has the sign bit set to 1, this would
represent a negative signed number. For example, suppose a byte contains
the value 82h. In this case the sign bit is set to 1 so the number is
-7Eh (or -126 decimal) if it is regarded as a signed number. Similarly
the value 81h in a byte is -7Fh (or -127 decimal). The value 80h in a
byte is -80h (or -128 decimal). But the value 7Fh is +7Fh (here the sign
bit is clear).
The sign bit is always the leftmost bit so in a byte it will be
bit 7, in a word it will be bit 15 and in a dword it will be bit 31.
This assumes we are calling the rightmost bit in all these cases
bit 0 (which is the traditional thing to do).
After most arithmetic instructions the
sign flag is set if the sign bit is set. This can
be tested to see if the number is negative after the instruction was
carried out.
Note that in a byte the number 0FFh is signed -1, 0FEh is signed -2 and
0F0h is signed -16 (decimal). So this sequence is decreasing. But
regarding the numbers as signed means that the sequence is also becoming
more negative.
Once you get more used to hex numbers this is easier to follow.
One way to calculate the value of a negative signed number is
to invert all the binary bits to find its complement, and add one
for example
0F0h in binary is 11110000
its complement is 00001111
which is 0Fh
add one 10h
which is 16 decimal
The first step here (the inverting of the binary bits) is called the
"one's complement". Adding the extra one is called using the
"two's complement". This is why signed numbers are also sometimes
called "two's complement" numbers.
One real advantage of this numbering system is that the same
instructions for the processor can be used whether the number is regarded
as a signed number or an unsigned number. This is because to the
processor, the number is the same. It is only how the number is regarded
by the programmer that distinguishes the number as a signed number.
There are some instructions, however when this does not work, notably
the multiply, divide and shift right instructions. In the case of the direct
multiply and divide instructions the special signed versions of these are
IMUL and IDIV (instead of MUL and DIV which are the
unsigned versions). There are three reasons why these are needed.
Firstly, when using
signed numbers, the sign of the result will depend on the sign of the
operands. A positive number multiplied by a negative number should give
the result as a negative number. Two negative numbers multiplied
together should give the result as a positive number. IMUL and IDIV
maintain the correct sign. MUL and DIV assume they are using positive
numbers only.
Secondly, the
result of the multiply and divide instructions are usually given in
a different data size than the operands. For example the result of a
32 bit multiplication will be given in the edx:eax register combination
which together make 64 bits. If the multiplication is using signed
numbers, it would be necessary for the sign bit to be at bit 63 in this
particular case. So the signed instructions ensure that the sign bit is
in the correct place. This is called "sign extending" the number.
Finally as we shall see, the signed instructions ensure that the
carry and overflow flags are correctly set to suit a signed result.
In the case of the shift right instruction, there is a special version
of this (SAR) which does not alter the high bit of the operand and so
maintains the correct sign in the result. This is not necessary for
left shifts since the sign is self-correcting, so although there is a
SAL mnemonic the opcode is the same as for SHL. This example proves
this to be correct:-
MOV AL,0FEh ;give al -2
SAR AL,1 ;divide by 2 - result in al is now 0FFh which is -1
MOV AL,0FEh ;give al -2
SAL AL,1 ;multiply by 2 - result in al is now 0FCh which is -4
Signed numbers also have their own set of
signed conditional jump instructions.
|