The reason being that HLLs suck, bad.

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.

Azu wrote:

The reason being that HLLs suck, bad.

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.

It's called "cdecl", and it does cause a noticeable gain in executable size.

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.

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.

proc printTest

  cinvoke wsprintf, .fmt

  ret
.fmt db "OldEBP = %X; RetAddr = %X;", 0
endp    

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.
    

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.

Since it already has this information (from the format string), ...

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.

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)..

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)..

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.

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

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

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.

 push ebp 
  mov ebp, esp 

  push .fmt 
  call wsprintf 

  leave 
  ret     

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

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

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.

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.

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)..

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..

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)..

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.