[MPlayer-dev-eng] Fixing the GCC-3.3 and scale code mess

[Zoltan Hidvegi]

Luca Barbato wrote:
> Zoltan Hidvegi wrote:
> > Yes, that's the best solution, and it will even speed up C code on
> > 64-bit machines, as the compiler no longer need to generate
> > unnecessary truncate and extend instructions.  int and unsigned local
> > variables and function arguments should all be changed to long and
> > unsigned long, and everyone should kick the habbit of using int.  int
> > and unsigned should *never* be used, if someone needs a specific data
> > size, use int32_t, otherwise, use long and unsigned long.
> 
> I miss the point.

If you do use int arithmetic on 64-bit platforms, the operations are
still performed using 64-bit registers, thus the result may not be
representable as an int.  The compiler has to insert trunctate or
sign-extend instructions.  Trivial example on PowerPC, take this
function:

int plus(int a, int b) { return a+b; }

This compiles to:

        add 4,3,4
        extsw 3,4

Now take long plus(long a, long b) { return a+b; } instead:

        add 3,3,4

One less instruction.  This is not that bad on x86-64, where the
operand size is part of the instruciton (leal vs. leaq), thus the
truncation is automatic, but I'm sure that there are situations even
on x86-64 where this is bad.

> > I tend to
> > like unsigned long the most, but it is too long to write, so I usually
> > like to have a typedef to ulong.  But ulong is defined by some systems
> > in system headers, so it is a bit of mess to get it right, because in
> > C, you cannot typedef ulong if it was already typedefed before, even
> > if it is the same type.
> 
> That's why you should avoid typedeffing base types...

I do not understand you comment here.  ulong is not a base type, but
that's not the point.  The point is that I like to use unsigned long,
but that's just too long to write, so I prefer to define some shorter
name to it.  It's just laziness.

Zoli