in the intel manual it says Quote "When an immediate value is used as an operand, it is sign-extended to the length of the destination operand format." - (that for the SUB instruction)
if the immediate is being treated as an unsigned integer wouldn't that change the value ? sign extending it, that is..
-
What the manual means is that it is sign extended IF you are using it with instructions that treat signed numbers, otherwise it is unsigned and the extended value is also unsigned. Extending the sign is, for example, AL->AX->EAX for 32 bit numbers.
Paul
i get it now, if iif I do.. sub eax, 20 it just represents 20 in 32bit form
only if i do something like sub eax, -20 it would sign extend -20 & evaluate the relults for signed integers. is that right ?
thanks paul.
RainStorm,
It looks like you have it. This stuff can be complicated but it is also fun, right?
Paul
lol yes ;)
Using hexadecimal to show the values.
-1 in hexadecimal as a byte, word, dword
ff, ffff, ffffffff
26 in hexadecimal as a byte, word, dword
1a, 001a, 0000001a
For sign extenstion the high bit of the byte fills the higher bits
of the word, the same for the word to dword.
Masm expects hexadecimal numbers to start with a number
and end with h, so ff would be 0ffh
and for 1a all the leading zeros aren't needed, just 1ah.
If you use decimal values it isn't as apparent.
The sign extension is most apparent in binary.
For signed integers
13 as a byte 00001101 the highest bit has a value of 0
-1 as a byte 11111111 the highest bit has a value of 1
the way a negative is encoded is by doing NOT on a positive then adding one
(the encoding is called two's complement, doing just the NOT is one's complement).
00000001 -> NOT -> 11111110 -> add 1 -> 11111111
and for -2
00000010 -> NOT -> 11111101 -> add 1 -> 11111110
For -2 from byte to word
11111110 -> 1111111111111110
yes i was aware of that, & the sign extension changes the value in the word, after it has been
extended from a byte, if it is treated as an unsigned value, that's why I asked the question.
..appreciate the help
Rainstorm.
-
Glad you've got it solved. If nobody minds I'll add my two cents:
The important distinction to make is that 'signed' and 'negative' are two different things. To use mathematical terms, an unsigned number has magnitude, a signed number has magnitude and sense. Positive and negative are only relevant for signed numbers. An unsigned number is neither positive or negative.
So, 100 could either be an unsigned number, or a positive signed number - there's no way of knowing. +100 is a positive signed number - the sign is specified explicitly so it must be signed. -100 is a negative signed number. It is a useful coincidence that unsigned numbers are stored in the same way as positive signed numbers, however, it can cause confusion. The IA32 architecture doesn't help as it often uses signed where it means negative (ie. the S bit, however, signed multiplication/division are correct).
As to the original query regarding the Intel documentation, this is specified because the SUB instruction can have an immediate operand specified in less bits than the destination, ie. it can subtract an 8-bit integer from a 32-bit register by internally sign-extending the source. The assembler handles this and shouldn't squeeze unsigned numbers between 128 and 255 (which could be misinterpreted as -128 to -1) into a single byte.
If all this was confusing, just ignore it, it's only interesting background :wink
Cheers,
Zooba :U
The immediate value is NOT being treated as an unsigned number. Those are words being inserted into the Intel description.
The fact that the SUB instruction is sign-extending the 8-bit value means the value is being treated as a signed number.