Leading Zero in Sign Extension in x86 Assembly?

Question

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 ﬁlled ECX ﬁrst with FFFFFFFFh and then copied signedVal to CX, the ﬁnal 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?

Margaret Bloom Margaret Bloom · Accepted Answer · 2016-04-18T08:49:28

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.

Leading Zero in Sign Extension in x86 Assembly?

2 Answers