flat assembler
Message board for the users of flat assembler.

Index > Windows > Win32 calls. Register usage?

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



Joined: 16 Dec 2008
Posts: 1159
Azu
The reason being that HLLs suck, bad. Evil or Very Mad
Post 08 Jun 2009, 08:03
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Azu wrote:
The reason being that HLLs suck, bad. Evil or Very Mad
Because time hasn't been spent on cooking up a non-standard calling convention that would show no noticable gain whatsoever in neither executable size nor runtime?

pal wrote:
OK I may make myself look like a complete idiot here; but what is wrong with having an API which takes varargs where the first argument in the API is the number of varargs e.g.
What would that save you? It adds a "push argcount" to get rid of a "add esp, argsize". In addition, now you don't have to go through just the hassle of matching a format string and the correct arguments, but also have to remember updating the argcount parameter.

_________________
Image - carpe noctem
Post 08 Jun 2009, 12:06
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1159
Azu
f0dder wrote:
Azu wrote:
The reason being that HLLs suck, bad. Evil or Very Mad
Because time hasn't been spent on cooking up a non-standard calling convention that would show no noticable gain whatsoever in neither executable size nor runtime?
It has. It's called "cdecl", and it does cause a noticeable gain (as in weight gain) in executable size and runtime memory usage (like 7 extra bytes each time it is used, and it is used like a billion times..)

f0dder wrote:
pal wrote:
OK I may make myself look like a complete idiot here; but what is wrong with having an API which takes varargs where the first argument in the API is the number of varargs e.g.
What would that save you? It adds a "push argcount" to get rid of a "add esp, argsize". In addition, now you don't have to go through just the hassle of matching a format string and the correct arguments, but also have to remember updating the argcount parameter.
Agreed. Like I've already said, there is no need to pass the arg count, since obviously the function knows how many args there are anyways.
Post 08 Jun 2009, 12:17
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: 17667
Location: In your JS exploiting you and your system
revolution
Azu wrote:
It's called "cdecl", and it does cause a noticeable gain in executable size.
I think you being far too sensitive to how "noticeable" it is. It adds, what, 3 or 4 bytes per call location in the code. So what, that will only have a seriously degrading effect if you have thousands of call sites and you have, for some unknown reason, put calls to wsprintf in the critical loops. If you DO have wsprintf in your critical code sections that you have written your code very badly. wsprintf is a helper function, not a core function for optimised code.
Post 08 Jun 2009, 12:24
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1159
Azu
revolution wrote:
Azu wrote:
It's called "cdecl", and it does cause a noticeable gain in executable size.
I think you being far too sensitive to how "noticeable" it is. It adds, what, 3 or 4 bytes per call location in the code. So what, that will only have a seriously degrading effect if you have thousands of call sites and you have, for some unknown reason, put calls to wsprintf in the critical loops. If you DO have wsprintf in your critical code sections that you have written your code very badly. wsprintf is a helper function, not a core function for optimised code.
Gee, let's make ExitThread take a kilobyte to call then, why not, it isn't used often right? You don't use it in critical loops, so WHO CARES. Rolling Eyes


On that note, how about we just remove opcodes like lea and prefixes like repne? They aren't NECCASARY.. sure they help make code a little faster but it does WORK without them so let's just toss them...

Who needs cars when you can just walk everywhere? Maybe they are a bit faster, but it's the same result in the end so who cares huh??? Laughing


The philosophy behind this HLL crap truly makes me sick. And drawing some line at some arbitrary point as to where it ends is just ignoring the problem.
Post 08 Jun 2009, 12:30
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:

Agreed. Like I've already said, there is no need to pass the arg count, since obviously the function knows how many args there are anyways.


Something you have accepted to be true even though the function is defined differently.

BTW, this is also valid:
Code:
proc printTest

  cinvoke wsprintf, .fmt

  ret
.fmt db "OldEBP = %X; RetAddr = %X;", 0
endp    
(same as above but with no macros)
Code:
printTest:
  push ebp
  mov ebp, esp

  push .fmt
  call wsprintf

  leave
  ret
.fmt db "OldEBP = %X; RetAddr = %X;", 0
; Ups, no add esp, 4 was needed.
; Ups number 2, how lucky we are wsprintf isn't stdcall, that would forced us to make a copy first to avoid stack corruption.
    


Not sure if it is supposed to be valid in and HLL or if it is just hacky, but since HLL are crap then I don't care, I know in Assembly is just valid to do what I did above.
Post 08 Jun 2009, 13:52
View user's profile Send private message Reply with quote
Azu



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

Agreed. Like I've already said, there is no need to pass the arg count, since obviously the function knows how many args there are anyways.


Something you have accepted to be true even though the function is defined differently.
I know for a fact that the function can and does detect how many variables it should have, and use them. The definition of what the function does is proof enough.

Since it already has this information (from the format string), it then follows that there is no need to pass it as another arg... unless there is some really weird limitation in HLLs that I don't know about, it should be able to count the %s and do an add esp at the end, or better yet just pop off the args as it parses the format string like in my example..
Post 08 Jun 2009, 14:20
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: 17667
Location: In your JS exploiting you and your system
revolution
Azu wrote:
Since it already has this information (from the format string), ...
Did you just decide to ignore the last part of LocoDelAssembly's post? What you say is WRONG, and no amount of repetition will suddenly make it right.
Post 08 Jun 2009, 14:24
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1159
Azu
revolution wrote:
Azu wrote:
Since it already has this information (from the format string), ...
Did you just decide to ignore the last part of LocoDelAssembly's post? What you say is WRONG, and no amount of repetition will suddenly make it right.
There's no way HLLs can make interesting code like that, if what you've said about them is correct, so I didn't have anything to say about it.

The function knows how many args are passed to it in his example, btw. There are two % so it takes 2 args (not counting first arg).. Smile

You can call it wrong all you want, it is extremely simple logic and very easy to see. Do I actually need to explain to you why it is possible for it to count how many % are in the string, even though it obviously does (based on its behavior)? You are being facetious!


Last edited by Azu on 08 Jun 2009, 14:32; edited 1 time in total
Post 08 Jun 2009, 14:28
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
i would like to point out that the difference between stdcall and cdecl is exactly 1 byte i size unless the function has more then 30ish arguments. also in some circumstances it can produce smaller exe files for example


push 1
push 2
push 3
call cdeclx

push 4
push 4
push 4
call cdecly

push 3215321
push 32532
push 211
push fish
call cdeclz

add esp, 28h ; no need to do it for each function. just do it the end

in this case your exe would be 3 bytes smaller than if it had used stdcall
Post 08 Jun 2009, 14:30
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17667
Location: In your JS exploiting you and your system
revolution
Azu wrote:
The function knows how many args are passed to it in his example, btw. There are two % so it takes 2 args (not counting first arg).. Smile
Yes, and popping them off the stack "automatically" would the the wrong thing to do in that code. A stdcall wsprintf would crash and burn.
Post 08 Jun 2009, 14:30
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1159
Azu
revolution wrote:
Azu wrote:
The function knows how many args are passed to it in his example, btw. There are two % so it takes 2 args (not counting first arg).. Smile
Yes, and popping them off the stack "automatically" would the the wrong thing to do in that code. A stdcall wsprintf would crash and burn.
What is your point? He isn't using any known calling standard, and there is no way any HLL will make code like that.



arigity wrote:
i would like to point out that the difference between stdcall and cdecl is exactly 1 byte i size unless the function has more then 30ish arguments. also in some circumstances it can produce smaller exe files for example


push 1
push 2
push 3
call cdeclx

push 4
push 4
push 4
call cdecly

push 3215321
push 32532
push 211
push fish
call cdeclz

add esp, 28h ; no need to do it for each function. just do it the end

in this case your exe would be 3 bytes smaller than if it had used stdcall
HLLs work like this? If they do, they will run into problems with running out of stack space eventually.. after to many of these functions, it will crash. Also, how does it handle it when they are in loops and conditional statements and stuff? It either won't be able to or it will do it in a messy way which will take much space and cycles..
Post 08 Jun 2009, 14:33
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:

What is your point? He isn't using any known calling standard, and there is no way any HLL will make code like that.

I've used cdecl in all the examples.
Post 08 Jun 2009, 14:35
View user's profile Send private message Reply with quote
Azu



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

What is your point? He isn't using any known calling standard, and there is no way any HLL will make code like that.

I've used cdecl in all the examples.
Okay so if I write in a HLL sprintf(fmt,esp,ebp) it makes this code
Code:
 push ebp 
  mov ebp, esp 

  push .fmt 
  call wsprintf 

  leave 
  ret     
????

Are you sure?

I don't believe this! There is no way they are that smart.


Last edited by Azu on 08 Jun 2009, 14:38; edited 1 time in total
Post 08 Jun 2009, 14:37
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:

Also, how does it handle it when they are in loops and conditional statements and stuff?

Either it will use "add esp, xx" after call or preallocate space on stack (via "sub esp, xx") and later use "mov [esp+xx], argX" for every argument that needs to be passed.
Post 08 Jun 2009, 14:38
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17667
Location: In your JS exploiting you and your system
revolution
Azu wrote:
What is your point? He isn't using any known calling standard, and there is no way any HLL will make code like that.
ALL HLL's make code like that everyday. The calling standard is CDECL. And your desire to make false assumptions and false statements, even after having been shown multiple times (by multiple people) that they are wrong, will not change the facts.
Post 08 Jun 2009, 14:39
View user's profile Send private message Visit poster's website Reply with quote
Azu



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

Also, how does it handle it when they are in loops and conditional statements and stuff?

Either it will use "add esp, xx" after call or preallocate space on stack (via "sub esp, xx") and later use "mov [esp+xx], argX" for every argument that needs to be passed.
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.
Post 08 Jun 2009, 14:39
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1159
Azu
revolution wrote:
Azu wrote:
What is your point? He isn't using any known calling standard, and there is no way any HLL will make code like that.
ALL HLL's make code like that everyday. The calling standard is CDECL. And your desire to make false assumptions and false statements, even after having been shown multiple times (by multiple people) that they are wrong, will not change the facts.
Post the HLL code then. I will compile it and see if it really makes the opcodes he posted. If it does I take back what I said.

P.S. also tell me what to compile it using..
Post 08 Jun 2009, 14:40
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:
revolution wrote:
Azu wrote:
The function knows how many args are passed to it in his example, btw. There are two % so it takes 2 args (not counting first arg).. Smile
Yes, and popping them off the stack "automatically" would the the wrong thing to do in that code. A stdcall wsprintf would crash and burn.
What is your point? He isn't using any known calling standard, and there is no way any HLL will make code like that.



arigity wrote:
i would like to point out that the difference between stdcall and cdecl is exactly 1 byte i size unless the function has more then 30ish arguments. also in some circumstances it can produce smaller exe files for example


push 1
push 2
push 3
call cdeclx

push 4
push 4
push 4
call cdecly

push 3215321
push 32532
push 211
push fish
call cdeclz

add esp, 28h ; no need to do it for each function. just do it the end

in this case your exe would be 3 bytes smaller than if it had used stdcall
HLLs work like this? If they do, they will run into problems with running out of stack space eventually.. after to many of these functions, it will crash. Also, how does it handle it when they are in loops and conditional statements and stuff? It either won't be able to or it will do it in a messy way which will take much space and cycles..


yes they do. you cannot ALWAYS do something like this (such as in a loop) but the compiler is usually spot-on when finding places where you can optimize code in this way.
Post 08 Jun 2009, 14:42
View user's profile Send private message Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1159
Azu
arigity wrote:
Azu wrote:
revolution wrote:
Azu wrote:
The function knows how many args are passed to it in his example, btw. There are two % so it takes 2 args (not counting first arg).. Smile
Yes, and popping them off the stack "automatically" would the the wrong thing to do in that code. A stdcall wsprintf would crash and burn.
What is your point? He isn't using any known calling standard, and there is no way any HLL will make code like that.



arigity wrote:
i would like to point out that the difference between stdcall and cdecl is exactly 1 byte i size unless the function has more then 30ish arguments. also in some circumstances it can produce smaller exe files for example


push 1
push 2
push 3
call cdeclx

push 4
push 4
push 4
call cdecly

push 3215321
push 32532
push 211
push fish
call cdeclz

add esp, 28h ; no need to do it for each function. just do it the end

in this case your exe would be 3 bytes smaller than if it had used stdcall
HLLs work like this? If they do, they will run into problems with running out of stack space eventually.. after to many of these functions, it will crash. Also, how does it handle it when they are in loops and conditional statements and stuff? It either won't be able to or it will do it in a messy way which will take much space and cycles..


yes they do. you cannot ALWAYS do something like this (such as in a loop) but the compiler is usually spot-on when finding places where you can optimize code in this way.
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..
Post 08 Jun 2009, 14:43
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5, 6 ... 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 GitHub, YouTube, Twitter.

Website powered by rwasa.