[Ffmpeg-devel] stdint.h and inttypes.h for non-C99 compilers

Christian Iversen chrivers
Sun Dec 17 01:53:59 CET 2006

On Saturday 16 December 2006 02:57, M?ns Rullg?rd wrote:
> Christian Iversen <chrivers at iversen-net.dk> writes:
> > On Friday 15 December 2006 13:50, M?ns Rullg?rd wrote:
> >> Christian Iversen said:
> >> > The stack is callee-cleared, and thus "register" is very much like
> >> > (perhaps identical to) Borland C++'s "__fastcall" modifier:
> >>
> >> Requiring the callee to restore the stack is simply stupid, IMHO.
> >
> > Well, that depends on the circumstance.
> Give an example where the callee restoring the stack would be better.

Well, in any case where you use a stack frame. The callee can collapse the 
stack frame + parameter block in 1 operation, the caller cannot.

Also, as you know, there's a specialized instruction (ret XX) for doing just 
that. It's not as efficient on modern processors as it used to be, but the 
calling convention is historic anyway.

> >> Imagine what would happen if a function like printf were called with too
> >> many arguments.
> >
> > What do you mean by "too many"?
> int foo, bar;
> printf("%d\n", foo, bar);

Oh, like that.

That never happens, because cdecl-style varargs are not used with the register 
CC, as I've mentioned.

Instead, some aux info is pushed on the stack, which ensures type safety and 
valid bounds. 

> > Pascal calling convention is not used with the same style of varargs
> > as cdecl, so the function will always know how many parameters it
> > has accepted. This is never a problem in practice.
> How is the number of arguments passed to the function?  Whatever the
> mechanism, it seems like a waste to me.

Well, if you are using a varargs-function for a _truly_ speed-critical 
function, you are always free to revert to cdecl, or use any number of other 
optimization tricks. (inlining, program specialization, metacode, etc).

In a large-scale (multi-media-oriented) project I'm working on, we've 
concluded that:

A) There's only a very small fraction of functions with varargs
B) Out of this small fraction, virtually none are speed-critical (mostly 
logging and similar functions).

It's really not much of a problem in practice, and the added type safety 
completely outweighs it. 

> > Of course, calling conventions on x86 is a mess anyway. Now, the x86_64
> > calling convention, that's something sane :-)
> Oh yes...

Good, we agree :)

Christian Iversen

More information about the ffmpeg-devel mailing list