# movzx question?

## Recommended Posts

do you have any explanation of why my by value of var1 is being transformed into a register of DWORD size before being passed into my std::cout function? is it just because it's more efficient? I will note i have optimization's turned off? Is there a purpose on this being compiled like this?

[code]
#include <iostream>

int main()
{
char Var1 = 'A';

std::cout << Var1;

getchar();
getchar();

return 0;
}
[/code]

[code]
_main PROC ; COMDAT

; 5 : {

push ebp
mov ebp, esp
push ecx

; 6 : char Var1 = 'A';

mov BYTE PTR _Var1$[ebp], 65 ; 00000041H ; 7 : ; 8 : std::cout << Var1; movzx eax, BYTE PTR _Var1$[ebp]
push eax
mov ecx, DWORD PTR __imp_?cout@std@@3V?$basic_ostream@DU?$char_traits@D@std@@@1@A
push ecx
call ??$?6U?$char_traits@D@std@@@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@D@Z ; std::operator<<<std::char_traits<char> >

; 9 :
; 10 : getchar();

call DWORD PTR __imp__getchar

; 11 : getchar();

call DWORD PTR __imp__getchar

; 12 :
; 13 : return 0;

xor eax, eax

; 14 : }

mov esp, ebp
pop ebp
ret 0
_main ENDP
_TEXT ENDS
END
[/code]

##### Share on other sites
It's being pushed, and everything on the stack is typically aligned to the processor word size (in this case 32-bits). Nothing to fear! As far as I know, all x86 compilers will do exactly what you see here.

The processor is usually more efficient when it's working with aligned data (and for a very small subset of instructions, the data MUST be aligned).

##### Share on other sites
[quote name='Nypyren' timestamp='1310673821' post='4835414']
It's being pushed, and everything on the stack is typically aligned to the processor word size (in this case 32-bits). Nothing to fear! As far as I know, all x86 compilers will do exactly what you see here.

The processor is usually more efficient when it's working with aligned data (and for a very small subset of instructions, the data MUST be aligned).
[/quote]

if the function was to accept a byte size parameter would it still perform the upconversion to DWORD size to increase performance? if that's the case in a way it changes the function's signature and code right?

##### Share on other sites
[quote name='nuclear123' timestamp='1310683324' post='4835464']
[quote name='Nypyren' timestamp='1310673821' post='4835414']
It's being pushed, and everything on the stack is typically aligned to the processor word size (in this case 32-bits). Nothing to fear! As far as I know, all x86 compilers will do exactly what you see here.

The processor is usually more efficient when it's working with aligned data (and for a very small subset of instructions, the data MUST be aligned).
[/quote]

if the function was to accept a byte size parameter would it still perform the upconversion to DWORD size to increase performance? if that's the case in a way it changes the function's signature and code right?
[/quote]
You're already calling a function that takes a byte-sized parameter; the parameter for [i]operator <<[/i] that takes char [i]is[/i] a byte-sized parameter,. But the calling convention followed by the compiler apparently states that the parameter shall be passed on the stack, and that he stack is quantized into 32-bit slots. The function takes an 8-bit parameter, and it is passed an 8-bit parameter, so I wouldn't say that the signature of the function is changed. The signature is only relevant on the language level, and on the language level a char is passed to, and is read by, the function. The fact that a whole 32-bit is written on the stack on machine instruction level is probably because the calling convention says so.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
627700
• Total Posts
2978695

• 21
• 14
• 12
• 10
• 12