Win32 calls. Register usage?

Index > Windows > Win32 calls. Register usage?

Goto page Previous 1, 2, 3 ... 5, 6, 7 ... 9, 10, 11 Next

Author

Thread

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 08 Jun 2009, 14:47

Quote:

Okay so if I write in a HLL sprintf(format,esp,ebp) it makes this code

Sorry, you told you are not interested in HLLs so why are you discussing this uninteresting aspect?

FYI, in an HLL (something you supposedly don't care) it would be just this:

Code:

printf(format);

And because you are not passing any vararg, printf will extract the information from what comes next to format (can't be clear this time, it could be EBP followed by RetADDR or local variables, etc).

Quote:

If it's doing it after each call then it isn't like you said in your example. It is normal super bloated way. Either way it is more bloated then it should be though.

Wonder how you manage to think my example have something to do with this scenario you proposed. And in the case of pre-allocation (i.e., allocating before using) obviously it is done before entering in the loop.

08 Jun 2009, 14:47

arigity

Joined: 22 Dec 2008
Posts: 45

arigity 08 Jun 2009, 14:50

Azu wrote:

Okay, so in some situations the amount of unneeded code is less then in others. It is still unneeded even in this situation. And in the loops and stuff it is even worse, which is where it matters most..

if it is done like this (which is frequently is) it may save size and speed over stdcall.

08 Jun 2009, 14:50

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 08 Jun 2009, 14:51

LocoDelAssembly wrote:

Quote:

Okay so if I write in a HLL sprintf(format,esp,ebp) it makes this code

Sorry, you told you are not interested in HLLs so why are you discussing this uninteresting aspect?

Because you guys keep talking about them? Or do you mean the calling standard is good because you can write some extreme niche case like that? If so, there are MUCH more efficient ways then that, if all you care about is single niche case which will never appear in a real application. It is still worse for everything else but this one case (print ebp and esp content).. which is probably never used except maybe in some kind of VM debugger type thing where you want to print registers.. but I'll post my own niche example below which would be even better for this, and work in the stdcall way

LocoDelAssembly wrote:

FYI, in an HLL (something you supposedly don't care) it would be just this:
Code:
printf(format);    
And because you are not passing any vararg, printf will extract the information from what comes next to format (can't be clear this time, it could be EBP followed by RetADDR or local variables, etc).

In other words, you are depending on undefined behavior...

LocoDelAssembly wrote:

Quote:
If it's doing it after each call then it isn't like you said in your example. It is normal super bloated way. Either way it is more bloated then it should be though.

Wonder how you manage to think my example have something to do with this scenario you proposed. And in the case of pre-allocation (i.e., allocating before using) obviously it is done before entering in the loop.

Sorry, thought you were replying to me.

arigity wrote:

Azu wrote:
Okay, so in some situations the amount of unneeded code is less then in others. It is still unneeded even in this situation. And in the loops and stuff it is even worse, which is where it matters most..

if it is done like this (which is frequently is) it may save size and speed over stdcall.

No.. still worse then the stdcall way which is just like how it is now except cleaning up after itself so tons of programs aren't littered with add esp,CONST all over the place..

Am I going to have to completely recreate the whole damn function and publish it and benchmarks for it before you'll believe??? Confused

Why?
Just take a quick look at how it is being done right now, you will see right away there is no reason it wouldn't work better pure stdcall non-wrapper way.. it knows the args passed due to the format string.. and there is no reason for it to parse them out of order.. and even if there was could just use internal counter to keep track of how many, instead of popping them as they are used, and do add esp thing inside function at least..

P.S. since you guys like random niche cases which will never be really used, I will make one to;

pusha
call StdStyleWsprintf

Just make sure eax points to format string that wants 7 values and what do you know Wink

even more efficient!
This can print all register except eax.. your niche example only print ebp and esp! And mine would be with normal calling standard.. yours is NOT stdcall... stdcall does not have weird "leave, ret" instructions at end!

Last edited by Azu on 08 Jun 2009, 15:12; edited 1 time in total

08 Jun 2009, 14:51

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 08 Jun 2009, 15:11

Preallocation example for loop using printf

Just to make some points:
* I don't care about the origins of cdecl, I know of them but my interest in having it for printf is not for plain desire to adhere to standards.
* When using varargs, cdecl is faster than stdcall (the variant that would support varargs).
* The code using printf would be sightly smaller in some situations and of the same size in others if stdcall (with varargs support) were used, but at the expense of extra execution time.

08 Jun 2009, 15:11

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 08 Jun 2009, 15:15

LocoDelAssembly wrote:

Preallocation example for loop using printf

Just to make some points:
* I don't care about the origins of cdecl, I know of them but my interest in having it for printf is not for plain desire to adhere to standards.
* When using varargs, cdecl is faster than stdcall (the variant that would support varargs).
* The code using printf would be sightly smaller in some situations and of the same size in others if stdcall (with varargs support) were used, but at the expense of extra execution time.

When I say stdcall, I do not mean the wvsprintf function which you pass parameters to in the heap. That is worse then passing them in the stack even if you have to clean up stack yourself..

I mean real stdcall version, where they are passed in stack, and function cleans them up Idea

No allocation would be needed within the function. You would obviously need pointer to allocated space for it to output to though, since that is what this function does.. it prints text into a buffer.. and no standard can effect this. Except maybe having it return the string in the stack, but that would be really really REALLY bad =/

08 Jun 2009, 15:15

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 08 Jun 2009, 15:19

Sorry, where I'm talking about wvsprintf?

08 Jun 2009, 15:19

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 08 Jun 2009, 15:24

LocoDelAssembly wrote:

cdecl is faster than stdcall (the variant that would support varargs).

I thought you were referring to the wvsprintf variant, since the true stdcall way would be faster then cdecl I.E.;

Program code

Code:

push arg1
push arg2
push arg3
call func
add esp,12

Code:

push arg1
push arg2
push arg3
call func

and

Library code

Code:

add ebp,4
mov eax,[ebp]

Code:

pop eax

Would be the main differences between the cdecl and true stdcall ways, and surely the latter are faster/smaller? Maybe not for functions that access them out of order, but wsprintf doesn't, and is the only cdecl Windows function, since C++ function != Windows function.

Last edited by Azu on 08 Jun 2009, 15:39; edited 1 time in total

08 Jun 2009, 15:24

arigity

Joined: 22 Dec 2008
Posts: 45

arigity 08 Jun 2009, 15:38

Azu wrote:

Library code

Code:

add ebp,4
mov eax,[ebp]

Code:

pop eax

curious, what library did you grab that code from?

stdcall pops the arguments off at the end (like a calling convention should) by retn xx

08 Jun 2009, 15:38

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 08 Jun 2009, 15:42

arigity wrote:

Azu wrote:
Library code
Code:
add ebp,4
mov eax,[ebp]    
vs
Code:
pop eax    
curious, what library did you grab that code from?

stdcall pops the arguments off at the end (like a calling convention should) by retn xx

In user32.dll and kernel32.dll all of the stdcall functions (I.E. all functions except wsprintf) use at least one pop.. look in IDA if you think I lie..

Last edited by Azu on 08 Jun 2009, 15:43; edited 2 times in total

08 Jun 2009, 15:42

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 08 Jun 2009, 15:42

Where do you see varargs there, which is the only case all but you are considering cdecl better over stdcall (with the appropiate modifications to support varargs since standard stdcall doesn't support them)?

08 Jun 2009, 15:42

arigity

Joined: 22 Dec 2008
Posts: 45

arigity 08 Jun 2009, 15:43

the pop is usually to restore ebp at the end which was saved at the start.....

08 Jun 2009, 15:43

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 08 Jun 2009, 15:45

LocoDelAssembly wrote:

Where do you see varargs there, which is the only case all but you are considering cdecl better over stdcall (with the appropiate modifications to support varargs since standard stdcall doesn't support them)?

None of them are vararg unless you count passing arg as 0, so nowhere. There is just this one single function that is vararg. When just one thing is doing it, it is not standard. They implemented the cdecl just for this one. Why? They could have gone with the stdcall like the others, or just made their own calling convention for it.. it is just one function, so a convention specialized for it would make more sense.. (not needed though since normal stdcall call works best)

arigity wrote:

the pop is usually to restore ebp at the end which was saved at the start.....

ebp shouldn't even be needed for this function. It is a artifact of the fixed arg count functions, not good for one like wsprintf.

08 Jun 2009, 15:45

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 19869
Location: In your JS exploiting you and your system

revolution 08 Jun 2009, 15:51

Azu wrote:

So why go out of their way to implement cdecl for just this one when they could do it stdcall way instead and have it more efficient?

Like you have already been told many times, they can't do it as stdcall. Don't you understand that point? Is that where you have the misconception? HLL can't do it, do you accept that? If you do then you must also accept that MS can't make it stdcall for that reason, and also that it is not actually stdcall anyway. stdcall doesn't support vararg. What you suggest is also a different calling standard so you are also committing the same "blasphemy" by introducing another calling standard for just one function.

And the efficiency is still in question.

08 Jun 2009, 15:51

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 08 Jun 2009, 15:54

revolution wrote:

HLL can't do it

I don't believe you. HLLs can call stdcall functions, and there is macro in FASM that works the same way (is called stdcall, fittingly), and I can use it to call functions that are like this, so HLL should be able to also.. if not, well, HLL sucks. Razz

All stdcall is is simple "push push push push call" sequence.. shouldn't be to hard..

08 Jun 2009, 15:54

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 19869
Location: In your JS exploiting you and your system

revolution 08 Jun 2009, 16:00

Azu wrote:

HLLs can call stdcall functions, and there is macro in FASM that works the same way (is called stdcall, fittingly), and I can use it to call functions that are like this, so HLL should be able to also.. i

Really? How does an HLL use stdcall to pass a variable number of arguments?

Azu wrote:

if not, well, HLL sucks.

What do you mean 'if not'? You already made the statement that it can. Which is it?

08 Jun 2009, 16:00

arigity

Joined: 22 Dec 2008
Posts: 45

arigity 08 Jun 2009, 16:02

Azu wrote:

ebp shouldn't even be needed for this function. It is a artifact of the fixed arg count functions, not good for one like wsprintf.

ebp is used for local variables too....

08 Jun 2009, 16:02

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 08 Jun 2009, 16:02

revolution wrote:

Azu wrote:
HLLs can call stdcall functions, and there is macro in FASM that works the same way (is called stdcall, fittingly), and I can use it to call functions that are like this, so HLL should be able to also.. i
Really? How does an HLL use stdcall to pass a variable number of arguments?

The same way it passes a "fixed" number of arguments. It shouldn't even be able to tell whether it is a "fixed" number or "variable" number, it is semantically called the same way.

revolution wrote:

Azu wrote:
if not, well, HLL sucks.
What do you mean 'if not'?

I mean if you're right.

arigity wrote:

Azu wrote:
ebp shouldn't even be needed for this function. It is a artifact of the fixed arg count functions, not good for one like wsprintf.

ebp is used for local variables too....

Okay, it is useful locally as a general purpose variable, you know what I meant though... I meant as frame pointer thingy.

08 Jun 2009, 16:02

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 19869
Location: In your JS exploiting you and your system

revolution 08 Jun 2009, 16:06

Azu wrote:

The same way it passes a "fixed" number of arguments. It shouldn't even be able to tell whether it is a "fixed" number or "variable" number, it is semantically called the same way.

You have a clear misunderstanding of HOW HLL's work. I suggest you try this in an HLL.

Code:

Sleep(1,2,3,4);

Will it compile for you? Answer: No, the compiler refuse to compile it. It gives an error: "wrong number of parameters passed".

08 Jun 2009, 16:06

arigity

Joined: 22 Dec 2008
Posts: 45

arigity 08 Jun 2009, 16:07

Azu wrote:

The same way it passes a "fixed" number of arguments. It shouldn't even be able to tell whether it is a "fixed" number or "variable" number, it is semantically called the same way.

stdcall uses retn const a the end of a function it cannot use vararg, it does not work that way. what you suggest puts near-retarded limitations, is ridiculously hard to implement, and almost completely removes any use for the stack ~at all~

08 Jun 2009, 16:07

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 08 Jun 2009, 16:07

If they really had to implement cdecl themselves can't be know, for instance, perhaps they just used the built-in functionality of the C compiler they probably used to code that function? cdecl exists way before Windows.

Also, I don't see why cdecl should be avoided for wsprintf, I don't care if it is for support HLLs or not, it just work good for varargs. Making wsprintf take care of ESP adjustment would make the code less efficient (speed-wise) and the fmt string would have to reference exactly the same amount of parameters that have been passed (currently you can reference less without relying on anything non standard).

08 Jun 2009, 16:07

Goto page Previous 1, 2, 3 ... 5, 6, 7 ... 9, 10, 11 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum