Jump to content
  • Advertisement
Sign in to follow this  
nuclear123

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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!