Re: calling convention stdcalll and cdecl call
"Alf P. Steinbach" <alfps@start.no> wrote in message
news:VKednQ8L0_gmEB7VnZ2dnUVZ_iydnZ2d@posted.comnet
* Igor Tandetnik:
Let's state it this way: I personally claim, looking at the details
of the two conventions, that the only advantage of stdcall over
cdecl lies in removing one machine instruction from the call site.
This is its one and only advantage over cdecl.
No, that is incorrect.
In what way is that incorrect?
You mean "ways".
Let's first consider stdcall with fixed number and types of
arguments. This point is not important, but from academic point of
view it is an extra advantage, thus, sufficient to say your statement
is not correct. The next two points, for variable number of
arguments, are of more practical significance, but you may be
unwilling to consider those points because current tools such as
Visual C++ do not implement those advantages (it is a tool
limitation).
The academic point, with fixed number and types of args: with cdecl
the function needs to return to the caller to have the stack area
used for arguments deallocated. With stdcall convention, when the
argument data is no longer needed it can freely deallocate that area
(by incrasing SP) and reuse it in calls to other functions.
So can cdecl, as long as at the end it leaves ESP as it found it:
; arguments no longer needed
add esp, <size of arguments>
call otherFunction
sub esp, <size of arguments>
Which
might matter when that area is large -- it's not an optimization
that I know any compiler to do, and it's only applicable in some
corner cases (large stack area, and for in practice no local
variables), but it is an optimization that is available with stdcall,
and not with cdecl.
That is incorrect. As I've shown, it is available with cdecl also.
Now let's consider stdcall with variable number of arguments and a
function that doesn't infer its other arguments from some known
argument(s). In that case, the requirements of stdcall /dictate/ that
somehow the argument stack area is passed: it is a direct logical
consequence of documented stdcall requirements.
Well, documented stdcall requirements state that it can't be used for
variadic functions in the first place, but I'll let it slide. I'm
assuming you are talking about your modified stdcall.
As a simple first example, consider then
void bar( ... );
void foo( ... ) { bar( someNotationForPassingOriginalArgs ); }
which includes the case of a recursive foo reusing args, and the
special case of a tail recursive foo reusing args.
I'm not sure I follow. Tail recursion is usually eliminated by simply
jmp-ing to the beginning of the function, not by mucking with stack
frames. That would work equally well in stdcall or cdecl function.
Basically, a tail recursion is rewritten as a loop - surely both stdcall
and cdecl functions can run loops.
And I don't see how non-tail recursion could reuse arguments. After all,
the original call would need to preserve some state in order to continue
with its work after the recursive call. How would it do that, while
allowing the recursive call to trample on its stack frame?
What is this someNotationForPassingOriginalArgs you are talking about?
Could you elaborate? Perhaps with an illustrative assembly sequence?
Works simply and nicely with stdcall (whichever general convention is
used to deal with this within the constraints of stdcall convention),
whereas with cdecl would need special purpose modification -- a
mechanism like the one for stdcall, rendering the whole point of
cdecl moot -- to do it.
Again, it's not clear to me from your description exactly _what_ works
simply and nicely with stdcall, and doesn't with cdecl. Could you
demonstrate these simple and nice workings?
As another and equally important example, with stdcall a function
such as printf has a means of checking that it has indeed been passed
enough bytes for the stated format specification: although the printf
function is of a form such that it doesn't know whether those bytes
are the right number and types of arguments, i.e. doesn't know enough
to determine that the call is OK, it does know enough to in many
cases say the call isn't OK (as with MS' newfangled buffer length
checking string handling functions). I think I mentioned this earlier
to you, but perhaps was to other guy.
I don't remember you mentioning it to me, but I do remember mentioning
it to you in the very post you are replying to.
I concede: your modified stdcall can catch some, but not all, misuses of
printf.
By all means. The technique you propose is different from
"traditional" __stdcall as currently implemented by VC compiler:
"not supported by tools". Are you suggesting there exists, or used
to exist, a compiler that implemented stdcall the way you describe?
If so, could you cite a reference? Otherwise, the technique is
properly characterized as "new", as in "never before implemented".
Oh, thanks. Yes, it's possible, although doubtful, that the technique
is new in the Microsoft world. However, it conforms fully to the
requirements on stdcall as documented at e.g. <url:
http://msdn.microsoft.com/en-us/library/zxk0tw93(VS.71).aspx>.
That is incorrect. First, this page states, and I quote: "the compiler
makes vararg functions __cdecl". Second, it doesn't document that the
compiler is allowed, even in some cases, to place additional information
on the stack beyond arguments themselves. Any such leeway would have to
be documented so that various tools could agree on precise stack layout
(which is, after all, the purpose of a calling convention).
You said your technique would support variadic functions. The
"traditional" stdcall doesn't (again, "not supported by tools"). I
assumed you would claim this fact as an improvement. However, if you
don't maintain your technique is an improvement, then we are in
agreement. It's been my point all along that the mechanism you
propose, while possible, is inferior to existing alternatives.
As I've stated I don't think it's in practice an improvement.
Great. So we _are_ in agreement after all.
However, the technique is probably not inferior to cdecl.
Well, it is in at least some respects. The call site is same size, but
the callee's epilogue is more involved for modified stdcall.
Perhaps there are other aspects where modified stdcall is better than
cdecl, but I have yet to see a convincing example of those (besides
printf guarding against stack overrun, which in my personal opinion is
not worth the bother: yours of course may differ).
Since cdecl
can always be used as an alternative except for e.g. the two cases
discussed above, which anyway aren't supported today, what matters in
practice is speed and size, where only measurements can tell, and
then perhaps not even in general but just for specific applications
and contexts. I think it would *probably* come out the winner on both
counts.
Since the call site is same size, and the function body is strictly
larger and more complicated, I don't see under what set of circumstances
modified stdcall can ever win such a benchmark. Definitely not by size,
which is predictable. Could you explain how modified stdcall can be
faster than cdecl, even theoretically? What combination of caching,
branch prediction or other arcane factors could possibly help it out? I
suspect (but don't have any proof, before you ask) that existing CPUs
are carefully optimized for existing calling conventions, rather than
hypothetical ones.
and furthermore supports more functionality and better safety
Are you talking about printf size checking case? I guess it counts as
better safety (though not by much), but more functionality? I've yet to
see an example of that.
Your
characterization as "inferior" is however not backed up by any
argument
That is incorrect. I have mentioned it many times before: the call site
is same size, but the function epilogue is larger with modified stdcall
than it is with cdecl.
and given your question above about advantages I think you
haven't even considered safety
I must admit I haven't before you mentioned it (I guess you could have
mentioned it before resorting to insults, but whatever). Having seen
your printf example, I'm not convinced it's much of an improvement,
though I concede it is some improvement.
and so I think you're simply flinging
adjectives about -- that you're not referring to the improved
safety as possibly backfiring, or indeed to anything, just an
unfounded stance.
I was referring to a point I had made many times previously in this
thread, and which you conveniently chose not to respond to. Here it is
again: the call site is same size, but the function epilogue is larger
with modified stdcall than it is with cdecl.
It seems to be an argument over terminology. You seem to say:
stdcall is any arrangement, no matter how complicated, where the
callee, rather than the caller, ends up cleaning the stack. I
concede: under this expanded definition of stdcall, it is possible
to have a stdcall variadic function.
How can you say that Microsoft's own definition of stdcall is an
expanded one?
What is the /unexpanded/ (in your view) definition of stdcall?
Microsoft's own definition of stdcall doesn't involve passing total
size of arguments to the callee. Your does, at least "in some
cases". In this sense yours is "expanded".
OK, but that's just a word game.
So is claiming that your "not supported by tools" stdcall is the same
calling convention as the "supported by tools" variety. Like I said,
it's an argument over terminology. Everything is relative, right?
Please provide a link to such unexpanded definition.
http://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
http://msdn.microsoft.com/en-us/library/a5s9345t.aspx
http://msdn.microsoft.com/en-us/library/25687bhx.aspx
On the last page, note the diagram of the stack frame for __stdcall
function. No evidence of total size, or any other additional
information beyond function arguments themselves.
He he, ROTFL. Have you consider a register?
Yes I have. The calling convention documents the use of registers, too.
Consider __thiscall and __fastcall, shown on this same page.
Not that concrete
examples that do not illustrate the relevant context, are relevant in
any way (disclaimer: I haven't looked at these examples, confident
that they're not relevant).
Well, given that we are talking about variadic functions, and that the
__stdcall documentation (the first cited page) says ""the compiler makes
vararg functions __cdecl", it's hard to expect an example of something
that's explicitly not supported.
It is not at all difficult to /design/ foo so that e.g. first
argument says how many arguments follow. Nor is it difficult to
provide foo with a library routine it can call in order to get
correct automatic stack cleanup prior to returning.
That's precisely the same as the compiler directive I said you would
need, the one you ridicule below.
Sorry, then I misunderstood you.
I wonder if, in the future, before calling people stupid, you might stop
and consider that perhaps you have misunderstood something they said. As
you see, it's a possiblity.
But anyway, the directive's only needed for effecting a silly
micro-optimization (perhaps I shouldn't have discussed it at all,
details tend to obscure the full view).
Well, it is precisely this micro-optimization that makes
currently-existing stdcall an improvement over cdecl. If you drop it,
then my argument, about modified stdcall being worse than cdecl
code-size-wise, stands.
Now that you mention safety, I think I understand the case your
mechanism is supposed to help with. You might be thinking of
something like printf("%d"). If the caller passes total size of
arguments to the callee, va_arg could be instrumented to check that
it doesn't reach beyond those arguments.
No, the mechanism is not supposed to help with that, it just emerges
as a distinct advantage. But yes, it seems that regarding what's
possible here, improved safety, we're now in agreement.
Could you give another example where safety is improved by using
modified stdcall over cdecl?
I guess it is possible
for the caller to prepare and pass a complete description of actual
argument types, and for va_arg to verify that it's used in accordance
with this description. That could be a valuable debugging aid, but
the overhead would probably be too high for production code.
Same as with MS's "safe" string functions.
Well, those don't quite go to _these_ lengths. They just take a buffer
size along with the buffer pointer: error checking is straightforward.
Many people consider them plenty fast for production code. Windows OS
source code itself reportedly uses them:
http://msdn.microsoft.com/en-us/library/ms995349.aspx
http://download.microsoft.com/download/8/6/5/8659f5ec-6eaa-4b1f-9107-3e1ec9edf39c/secure_platform.doc
(search for "string handling"). At the very least, Microsoft is
definitely pushing them for use in production code, not just for
debugging.
Are there other scenarios where cdecl is less safe than stdcall
(whether "traditional" or "expanded")?
Don't know. Please don't make me think. :-)
Ah. So you state a claim, but decline to back it with any argument.
Isn't that the same sin you often accuse me of?
Hmm, I wonder what one might call a person who refuses to think. Perhaps
one or more of the terms you used to describe me might fit?
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925