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

Måns Rullgård mru
Sun Dec 17 14:30:32 CET 2006


Christian Iversen <chrivers at iversen-net.dk> writes:

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

The caller could combine the stack pointer restoration with some other
stack pointer operation, such as preparing it for calling another
function or before returning.

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

That's only on x86.  I was talking about the general case.

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

I wasn't talking about the x86 register cc, I was talking about
callee-popped arguments in general.

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

Runtime checks are for wimps. ;-)

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

What language is this done in?

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

Have you ever looked at a decent RISC design?

-- 
M?ns Rullg?rd
mru at inprovide.com




More information about the ffmpeg-devel mailing list