How does sign extension from signed char to sign int works?

Question

Why does a 255 value represented by a signed char, get converted to -1 with an integer? I see a mov sbl instruction being used by x86 to convert a signed char to a signed int, but why does it convert in the way it does now?

Answer 1

Assuming an 8-bit char, an object of type signed char can never have a value 255. When you assign 255 to such an object, it gets converted in an implementation-defined manner (which, in reality, is always reduction modulo 256 into the range). Thus, it already has value -1 at this point. Converting that to type int makes no change at all.

Answer 2

Sign extension works by checking the high bit of the value and extending from there. 255 is all 1's as unsigned therefore when it's sign extended it's padded with 1's. All 1's in signed integer format is -1.

I noticed you said 255 as signed char. Max value of signed char is actually 127. If you do

char a = 255;

you will actually get -1 in some compilers. Unsigned char can hold 255 though.

Answer 3

The instruction movsb{w,l,q} looks at the "top bit" in the byte, and fills the remaining bits of the word (16, 32 or 64 bits) with that value.

The sister instruction to this is movzb{w,l,q}, which zero extends (that is, does an "unsigned extension".

In 64-bit x86, 32-bit operations automatically zero-fills the upper 32-bit, so to extend a 32-bit value to 64-bit, the compiler will add an movslq to extend the 32-bit number to 64-bits.

There is also movswl and movswq to extend 16-bit registers to 32 and 64 bits respectively.