CODEWITHSUNDEEP
assemblybinaryx86hexunsigned
user3661613
user3661613

Reputation: 107

Leading Zero in Sign Extension in x86 Assembly?

I read Kip IRVINE's book Assembly Language for x86 Processors and he wrote:

Copying Smaller Values to Larger Ones

Although MOV cannot directly copy data from a smaller operand to a larger one, programmers can create workarounds. Suppose count (unsigned, 16 bits) must be moved to ECX (32 bits). We can set ECX to zero and move count to CX:

.data
count WORD 1
.code
mov ecx,0
mov cx,count

What happens if we try the same approach with a signed integer equal to -16?

.data
signedVal SWORD -16 ; FFF0h (-16)
.code
mov ecx,0
mov cx,signedVal ; ECX = 0000FFF0h (+65,520)

The value in ECX (+65,520) is completely different from -16. On the other hand, if we had filled ECX first with FFFFFFFFh and then copied signedVal to CX, the final value would have been correct:

mov ecx,0FFFFFFFFh
mov cx,signedVal ; ECX = FFFFFFF0h (-16)

My problem is with last part. I think the first line in the code above we should have written mov ecx,FFFFFFFFFh, not 0FFFFFFFFh. In other words what is the leading zero?

Upvotes: 2

Views: 2288

Answers (2)

Andreas H.
Andreas H.

Reputation: 1811

To distinguish between symbols (i.e. variables) and numbers you have to start numbers with a decimal digit.

The numeric parameter to mov ecx, is always stored as 32-bit regardless of the number if digits you write in the code (as long as the final value is less than 2^32). Leading zeros are ignored.

In contrast to C/C++ numbers starting with 0 are not interpreted as octal numbers (if that is your concern). Octal numbers are startet with 0t.

Upvotes: 0

Margaret Bloom
Margaret Bloom

Reputation: 44146

In order to tell labels and numeric literals apart most assemblers require the latter ones to always begin with a digit, even if it is just a non significant zero.

If you count the number of significant hex digits in 0ffffffffh you see that they are indeed eight, each one carrying four bits of information.
And 8 times 4 is 32.
Your literal fffffffffh is 36 bits long instead.

Simply put numbers like dah a7h, e0h and so on, must be written with a leading 0.
In your mind you should get automatically rid of superfluous zeros.

Upvotes: 5

Related Questions