flat assembler
Message board for the users of flat assembler.

Index > Windows > Win32 calls. Register usage?

Goto page Previous  1, 2, 3 ... 6, 7, 8, 9, 10, 11  Next
Author
Thread Post new topic Reply to topic
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
revolution wrote:
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".
Wtf? Did the guy who made it, like, hard code the number of args each win32 function takes and go out of his way to make it fail if you put in a different number? Why??? Aside from killing all vararg, this would also make it impossible to push args for the next function..

And what about functions he didn't know of? Like if you import functions from your own library? Does the HLL explode or something? ROFL! HLL sounds shittier and shittier the more you tell me about it.



LocoDelAssembly wrote:
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).
How is passing the wrong number of arguments, invoking undefined behavior, good for performance (or good for anything, for that matter)? It will still try to read them.. but it will be reading some random garbage data instead!


Last edited by Azu on 08 Jun 2009, 16:15; edited 1 time in total
Post 08 Jun 2009, 16:12
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
So now you finally understand stdcall? Yes? That is part of stdcall, it cannot support vararg. Okay, now you accept?
Post 08 Jun 2009, 16:14
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
Okay read what I write before replying, yes? Well, can you?


Last edited by Azu on 08 Jun 2009, 16:16; edited 1 time in total
Post 08 Jun 2009, 16:15
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
And to answer 'WHY': because you want it to clean up the stack so of course you have to tell it how many arguments to accept. Do you finally "get it"? Please say yes!
Post 08 Jun 2009, 16:16
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
revolution wrote:
Ans to answer 'WHY': because you want it to clean up the stack so of course you have to tell it how many arguments to accept. Do you finally "get it"? Please say yes!
Image

Why do you try to reply to what I wrote without first reading it? You are just spamming/trolling now.. Sad
Post 08 Jun 2009, 16:17
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
arigity



Joined: 22 Dec 2008
Posts: 45
arigity
stdcall functions ONLY clean up the number of args it knows it has. if you push more you will screw everything else up, thus the compiler will not compile because it knows that what you put in will cause it to crash.

compilers can only do what you tell it to do. you need to tell it beforehand information about the specific call, this is done in different ways for various HLL's.
Post 08 Jun 2009, 16:20
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

How is passing the wrong number of arguments, invoking undefined behavior, good for performance (or good for anything, for that matter)? It will still try to read them.. but it will be reading some random garbage data instead!

In the text you quoted from me could you tell me where I'm passing the wrong number of arguments?

Also, even if I would have said passing wrong number of arguments (also possible to do with any stdcall function so I don't get how this has something to do with the discussion), how comes it will be bad for performance when the right (and the way you see "right", i.e., fmt references all the varargs not allowing to reference less) number of args are passed?
Post 08 Jun 2009, 16:21
View user's profile Send private message Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
arigity wrote:
stdcall functions ONLY clean up the number of args it knows it has. if you push more you will screw everything else up, thus the compiler will not compile because it knows that what you put in will cause it to crash.

compilers can only do what you tell it to do. you need to tell it beforehand information about the specific call, this is done in different ways for various HLL's.
Like I explained.. over 10 times already.. it does know how many args are pushed to it, I even posted a proof of concept code proving this. Each time it encounters a %, that is one arg. What is so hard to understand? Do you think wsprintf just MAGICALLY knows how many to read, instead of the logical explanation? -.-



LocoDelAssembly wrote:
Quote:

How is passing the wrong number of arguments, invoking undefined behavior, good for performance (or good for anything, for that matter)? It will still try to read them.. but it will be reading some random garbage data instead!

In the text you quoted from me could you tell me where I'm passing the wrong number of arguments?

Also, even if I would have said passing wrong number of arguments (also possible to do with any stdcall function so I don't get how this has something to do with the discussion), how comes it will be bad for performance when the right (and the way you see "right", i.e., fmt references all the varargs not allowing to reference less) number of args are passed?
Well you said cdecl should be used, so that you can pass the wrong amount of args.. this implies that passing the wrong amount of args (and the function thus trying to read args that don't exist) is a good thing.

I think it is a bad thing though.
Post 08 Jun 2009, 16:23
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2915
Location: [RSP+8*5]
bitRAKE
Borsuc wrote:
I agree hybrids are good, but I still don't see why would anyone use cdecl.
Imagine calling the same function with slightly different parameters. For example, sending several messages to the same control. STDCALL requires preserving parameters elsewhere to be pushed repeatedly. Whereas, CDECL allows just updating existing parameters on the stack - the parameter space acts as temporary storage through CALLs.

Also, objects can be constructed on the stack when interfaces are organized in a appropriate manner. At one level, for instance, we are working with interfaces which operate on points (two values on the stack); and then at a higher level we operate on triangles (three points on the stack). Using ENTER/LEAVE provides locals from BP while allowing dynamic construction with SP.

This is how the instruction set was designed to be used! Sadly, too few have actually perfected the art of it's use, and HLL programmers are constantly pushing (pun intended) for interfaces which are easy for a compiler to optimize (Intel is to blame here as well, imho). <SARCASM> We don't actually want to employ thinking people, or worse yet have to trust them! </SARCASM>

_________________
¯\(°_o)/¯ unlicense.org


Last edited by bitRAKE on 08 Jun 2009, 16:43; edited 1 time in total
Post 08 Jun 2009, 16:27
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
bitRAKE wrote:
Borsuc wrote:
I agree hybrids are good, but I still don't see why would anyone use cdecl.
CDECL allows just updating existing parameters on the stack - the parameter space acts as temporary storage through CALLs.
Someone else in this thread said that it gets trashed and thus can't be reused..
Post 08 Jun 2009, 16:30
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
arigity



Joined: 22 Dec 2008
Posts: 45
arigity
Azu wrote:
Like I explained.. over 10 times already.. it does know how many args are pushed to it, I even posted a proof of concept code proving this. Each time it encounters a %, that is one arg. What is so hard to understand?


your not getting it at all, listen, your wrong. your way won't work without major complications. it is a terrible standard to even suggest because it requires radical alterations to already existing code, destroys the usefullness of the stack, and imposes a gajillion restrictions that i cannot even begin to fathom all in the name of putting an end to a single instruction.

Azu wrote:
Wtf? Did the guy who made it, like, hard code the number of args each win32 function takes and go out of his way to make it fail if you put in a different number? Why??? Aside from killing all vararg, this would also make it impossible to push args for the next function..


see ->
Quote:
stdcall functions ONLY clean up the number of args it knows it has. if you push more you will screw everything else up, thus the compiler will not compile because it knows that what you put in will cause it to crash.


this was directed at that.
Post 08 Jun 2009, 16:31
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

Well you said cdecl should be used, so that you can pass the wrong amount of args.. this implies that passing the wrong amount of args (and the function thus trying to read args that don't exist) is a good thing.

I think it is a bad thing though.


This doesn't happens when fmt reference LESS (LESS, LESS!!!!) arguments than passed.

BTW, insisting on the problem of bad number of arguments doesn't prove the method shown in your proof of concept is better, it is clearly less efficient (speed-wise) and it is a nightmare to keep local variables that way.
Post 08 Jun 2009, 16:33
View user's profile Send private message Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
revolution wrote:
If you are generating a PE file then you will only see a reduction in size if it passes a page boundary (512B). And your code will fail if you try to access into the next VM page.
Code:
format PE ...
...
mov [any_data],eax ;CRASH: the data has not been paged into your memory or you overwrite the following page of data
.data
string1 db 'Hello world!',0  ;13 bytes forces a new 512 byte section in file
some_data = $ ;Okay if you have less than 4083 bytes used at runtime
any_data = $+4096 ;error at runtime, the data was not reserved!    
What's that have to do with wsprintf?

arigity wrote:
Azu wrote:
Like I explained.. over 10 times already.. it does know how many args are pushed to it, I even posted a proof of concept code proving this. Each time it encounters a %, that is one arg. What is so hard to understand?


your not getting it at all, listen, your wrong. your way won't work without major complications. it is a terrible standard to even suggest because it requires radical alterations to already existing code, destroys the usefullness of the stack, and imposes a gajillion restrictions that i cannot even begin to fathom all in the name of putting an end to a single instruction.
???
There is only one functions that would be altered.. and none of the "restrictions" anyone has mentioned so far are a problem for that.

arigity wrote:
Azu wrote:
Wtf? Did the guy who made it, like, hard code the number of args each win32 function takes and go out of his way to make it fail if you put in a different number? Why??? Aside from killing all vararg, this would also make it impossible to push args for the next function..


see ->
Quote:
stdcall functions ONLY clean up the number of args it knows it has. if you push more you will screw everything else up, thus the compiler will not compile because it knows that what you put in will cause it to crash.


this was directed at that.
It was directed at whatever it was quoting..


LocoDelAssembly wrote:
Quote:

Well you said cdecl should be used, so that you can pass the wrong amount of args.. this implies that passing the wrong amount of args (and the function thus trying to read args that don't exist) is a good thing.

I think it is a bad thing though.


This doesn't happens when fmt reference LESS (LESS, LESS!!!!) arguments than passed.

BTW, insisting on the problem of bad number of arguments doesn't prove the method shown in your proof of concept is better, it is clearly less efficient (speed-wise) and it is a nightmare to keep local variables that way.
Of course it should be optimized and filled out if you want to use it in production Razz hence why it is a proof of concept, not a "directly copy and paste this over the current function to zoop up your computer lololol".

P.S. passing more arguments then needed is bad for performance, not good for it.






* walks off to bed, grumbling about you all getting talkative right as he's getting ready for an stdcall [Sleep],1000*60*60*8 Sad *


Last edited by Azu on 08 Jun 2009, 16:56; edited 1 time in total
Post 08 Jun 2009, 16:35
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2915
Location: [RSP+8*5]
bitRAKE
Azu wrote:
bitRAKE wrote:
Borsuc wrote:
I agree hybrids are good, but I still don't see why would anyone use cdecl.
CDECL allows just updating existing parameters on the stack - the parameter space acts as temporary storage through CALLs.
Someone else in this thread said that it gets trashed and thus can't be reused..
...that someone else should code differently. Compilers can't solve the interface problem without a lame model - they are neutered from the start to produce less optimal code. Therefor, I don't see the benefit in using the same lame model to limit my programming.

Now, if we are talking about interfacing an existing API then of course that will dictate our options, but it is a completely different thing than actually coding one's own.

_________________
¯\(°_o)/¯ unlicense.org
Post 08 Jun 2009, 16:56
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
bitRAKE wrote:
Azu wrote:
bitRAKE wrote:
Borsuc wrote:
I agree hybrids are good, but I still don't see why would anyone use cdecl.
CDECL allows just updating existing parameters on the stack - the parameter space acts as temporary storage through CALLs.
Someone else in this thread said that it gets trashed and thus can't be reused..
...that someone else should code differently. Compilers can't solve the interface problem without a lame model - they are neutered from the start to produce less optimal code. Therefor, I don't see the benefit in using the same lame model to limit my programming.

Now, if we are talking about interfacing an existing API then of course that will dictate our options, but it is a completely different thing than actually coding one's own.
Agreed, HLLs are a hopeless cause.
Post 08 Jun 2009, 16:58
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
arigity



Joined: 22 Dec 2008
Posts: 45
arigity
Azu wrote:
There is only one functions that would be altered.. and none of the "restrictions" anyone has mentioned so far are a problem for that.



any function using your standard would need to be radically altered, and (aside from your function killing the usefullness of the stack) all three ones i pointed out will be a problem for any non-trivial function that uses it. (having to read in same order pushed, having to always read every arg, and only being to read it once)

ironically, your calling standard might only be useful for a handful of functions which is why you were complaining about cdecl at the start...

Azu wrote:
*walks off to bed, grumbling about you all waking up right as he's getting ready for an stdcall [Sleep],28'800'000*


good night.
Post 08 Jun 2009, 16:58
View user's profile Send private message Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
arigity wrote:
Azu wrote:
There is only one functions that would be altered.. and none of the "restrictions" anyone has mentioned so far are a problem for that.



any function using your standard would need to be radically altered, and (aside from your function killing the usefullness of the stack) all three ones i pointed out will be a problem for any non-trivial function that uses it. (having to read in same order pushed, having to always read every arg, and only being to read it once)

ironically, your calling standard might only be useful for a handful of functions which is why you were complaining about cdecl at the start...
It isn't a new calling standard, it's just how the vararg function, wsprintf, should use stdcall.. so that code is smaller, and all the Windows functions will use the same standard.

arigity wrote:
Azu wrote:
*walks off to bed, grumbling about you all waking up right as he's getting ready for an stdcall [Sleep],28'800'000*


good night.
Thanks. I reckon this will be to page 10 when I get up hehe.
Post 08 Jun 2009, 17:02
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

P.S. passing more arguments then needed is bad for performance, not good for it.

In my first example is probably better than branching which has serious performance hit when a branch misprediction occurs.

However, are you trying to make me believe that because of this thing of passing more parameters is not optimal then your stdcall will be better in the mayority of the varargs cases? I'm still waiting of a single case your idea will be better but yet none, you only show how simple is call with your customized stdcall, but completely hiding the real speed costs.

BTW, you PoC simply crash always.
Post 08 Jun 2009, 17:02
View user's profile Send private message Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1160
Azu
LocoDelAssembly wrote:
Quote:

P.S. passing more arguments then needed is bad for performance, not good for it.

In my first example is probably better than branching which has serious performance hit when a branch misprediction occurs.

However, are you trying to make me believe that because of this thing of passing more parameters is not optimal then your stdcall will be better in the mayority of the varargs cases? I'm still waiting of a single case your idea will be better but yet none, you only show how simple is call with your customized stdcall, but completely hiding the real speed costs.


You are already making a branch, just put the arg in that, problem solved. Now lemme sleep :<


LocoDelAssembly wrote:
BTW, you PoC simply crash always.
You'll just have to guess what it is supposed to do then. I'm not going to waste time fixing it when it is just meant to illustrate a simple idea, which you know damn well would work fine if the function was made that way. Razz
Post 08 Jun 2009, 17:09
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
Azu wrote:
revolution wrote:
If you are generating a PE file then you will only see a reduction in size if it passes a page boundary (512B). And your code will fail if you try to access into the next VM page.
Code:
format PE ...
...
mov [any_data],eax ;CRASH: the data has not been paged into your memory or you overwrite the following page of data
.data
string1 db 'Hello world!',0  ;13 bytes forces a new 512 byte section in file
some_data = $ ;Okay if you have less than 4083 bytes used at runtime
any_data = $+4096 ;error at runtime, the data was not reserved!    
What's that have to do with wsprintf?
Ermm, nothing whatsoever. But why do you drag in a post from another thread and paste it here as if to say I posted it here? Very bad manners!
Post 08 Jun 2009, 17:09
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3 ... 6, 7, 8, 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


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.