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

[Christian Iversen]

On Sunday 17 December 2006 14:30, M?ns Rullg?rd wrote:
> 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.

That's true, but only if the caller knows the size of the stackframe, or if 
the previous SP was saved.

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

But we were talking about an x86-specific CC! I've never agreed to 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.

But I was! Surely that counts for something :)

> > Instead, some aux info is pushed on the stack, which ensures type
> > safety and valid bounds.
>
> Runtime checks are for wimps. ;-)

Crashes are for suckers ;-)

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

Object Pascal, specifically the FreePascal variety.

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

I've looked at MIPS, Alpha and Sparc. I'll let you be the judge of the 
function decent(x).

And I thought it was implied that we were talking about sane CISC CC's :)

-- 
Regards,
Christian Iversen