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

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

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!

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!

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.

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?

I agree hybrids are good, but I still don't see why would anyone use cdecl.

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.

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?

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

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.

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.

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!    

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.

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.

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

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.

There is only one functions that would be altered.. and none of the "restrictions" anyone has mentioned so far are a problem for that.

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

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.

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

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.

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?