Public Group

# movzx question?

This topic is 2558 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## 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?

 #include <iostream> int main() { char Var1 = 'A'; std::cout << Var1; getchar(); getchar(); return 0; } 

 _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> > add esp, 8 ; 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 

##### 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

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).

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='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).

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 operator << that takes char is 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.

1. 1
2. 2
Rutin
19
3. 3
JoeJ
16
4. 4
5. 5

• 30
• 22
• 13
• 13
• 17
• ### Forum Statistics

• Total Topics
631700
• Total Posts
3001800
×