flat assembler
Message board for the users of flat assembler.
![]() Goto page 1, 2, 3 ... 9, 10, 11 Next |
Author |
|
booter
Which registers are used by Win32 calls?
I mean, should it always be like that? Code: pushad invoke someWin32 mov dword [esp+28],eax ; return eax popad Thanks |
|||
![]() |
|
revolution
The Win32 API uses Stdcall.
|
|||
![]() |
|
revolution
bitshifter wrote: Also note that a few like wsprintf use cdecl calling convention. |
|||
![]() |
|
pal
Why would you pushad then move a value into a register for it to be removed when you use popad.
Quote:
|
|||
![]() |
|
revolution
[esp+28] points the the location where eax will be poped from.
|
|||
![]() |
|
manfred
revolution wrote: Actually, just that one function only. _________________ Sorry for my English... |
|||
![]() |
|
revolution
If you like, wsprintfA and wsprintfW.
|
|||
![]() |
|
Borsuc
cdecl is stupid. Seriously why the hell should the caller clean the stack? Does it expect you to call the same function twice or something?
|
|||
![]() |
|
revolution
For variable argument counts. Else how?
|
|||
![]() |
|
LocoDelAssembly
Quote:
That doesn't justify the convention as the parameters are considered garbage at return so you must load them again. Code: // Example of a function that would destroy the parameter (supposing no optimizations are performed) int sum(int a, int b) { a += b; // Allowed, parameters work like pre-initialized variables return a; } // Some caller accum = 0; for (i = 0; i < 10; i++) for (j = 0; j < 10; j++) accum += sum(j,i); // Here would be an error reusing the 2nd parameter There must be some benefit over stdcall, but parameter reusing is not one of them. |
|||
![]() |
|
Borsuc
revolution wrote: For variable argument counts. Else how? What Loco said further outlines it. I seriously think it should be scrapped totally. _________________ Previously known as The_Grey_Beast |
|||
![]() |
|
Plue
> There must be some benefit over stdcall
Yes, most c compilers use it by default. And vararg functions are somewhat faster (although all other functions are slower). Really, there is no benefit. It was simply designed by sillies and now we're stuck with it. |
|||
![]() |
|
f0dder
Borsuc: how would you make a VARARG function do stack cleanup?
Plue wrote: Really, there is no benefit. It was simply designed by sillies and now we're stuck with it. By the way, you don't have to "add esp, xx" after every function call for cdecl... |
|||
![]() |
|
manfred
Vararg function doing stack cleanup, simple solution:
Code: func: ; foo bar ; ecx=sizeof(args) pop edx add esp, ecx jmp edx _________________ Sorry for my English... |
|||
![]() |
|
f0dder
manfred: which will defeat the CALL/RET pairing optimization that some CPUs have. Also, in the case that arguments aren't exactly matched, you will be returning to never-never land.
|
|||
![]() |
|
revolution
Let's go and visit Peter Pan and friends:
Code: ... mov ebp,esp stdcall printf,"%d%d%d%d%d",eax ;oops only one parameter! mov esp,ebp ret printf: ;foo bar pop edx add esp,4*5 jmp edx ![]() Yeah, I know, a corner case, but just sayin'. |
|||
![]() |
|
manfred
f0dder wrote: manfred: which will defeat the CALL/RET pairing optimization that some CPUs have. _________________ Sorry for my English... |
|||
![]() |
|
Borsuc
f0dder wrote: Borsuc: how would you make a VARARG function do Code: push string ; assume it is "%d%d" push eax push ecx push 2*4 call printf ... printf: pop eax pop ecx add esp, ecx push eax ret And if you care about speed, well. Don't use VARARG functions ![]() f0dder wrote: "Stuck with it"? If you don't like cdecl, write your functions as stdcall or fastcall, problem solved. f0dder wrote: By the way, you don't have to "add esp, xx" after every function call for cdecl... _________________ Previously known as The_Grey_Beast Last edited by Borsuc on 18 May 2009, 17:25; edited 1 time in total |
|||
![]() |
|
f0dder
Borsuc wrote: Nope, what if you use an API that uses it? Borsuc wrote:
|
|||
![]() |
|
Goto page 1, 2, 3 ... 9, 10, 11 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.