[XviD-devel] ia64-Patch

suxen_drol xvid-devel@xvid.org
Sun, 26 Jan 2003 12:55:27 +1100


On Sat, 25 Jan 2003 18:42:46 +0100 (CET) Christoph Lampert <chl@math.uni-bonn.de> wrote:

> On Sat, 25 Jan 2003, Stephan Krause wrote:
> 
> > Hi,
> > 
> > after a longer time i checked the code for ia64 compatibility, and it did 
> > segfault in mbcoding. Reason was a uint32 which became -1. On 32bit-Platforms 
> > this is not a Problem, but on ia64 this isn't a really good idea. Using ptr_t 
> > instead of uint32 does help (on x86, ptr_t is just the same as uint32_t)

i have applied the patch. but i wonder why it was crashing, because most
(if not all) of the varibles are used to index an array (so these really
arent pointers, just indexs)

	ie. level = some_table[i][j][k];

currenlty ptr_t is defined as an unsinged integer, but i noticed a
warning in mbcoding.c when we do -level (where level is a ptr_t).

> Yes, we should really take more care about correct types, in particular
> with "64bit for everybody" around the corner: 
> 
> My suggestion: 
> 
> * Use "natural" types where possible. Use "int" instead of int32_t, etc.,
>   unless the size matters (which it almost never does). The _size_ of
>   structures doesn't have to be the same on every plattform... 

yes i agree.

> * Of course, things like "uint8_t" for 8bit images and "int16_t" for
>   DCT data must be the same, but e.g. length of MV entries doesn't have 
>   to. I doubt that XVID will ever run successfully on a machine with 
>   16bit integers, so range should always be sufficient... 

i wonder if we should support different types for dct samples.
ie. on a non-simd machine, the dct-operations would be better perform in
the natural int type (rather than int16_t).

> * Use  unsigned int  for loop counters (I read somewhere that it's
>   faster), unless they become negative, of course.

it might be faster on some obsure platform. or unsigned loops may be
less confusing for the compiler. but, if a functions speed if affected
by loop performance then it really should be hand-optimized in assembly.

> * When in doubt, use signed types (in particular SAD-values, MVs)
> 
> * For status values, used signed types (speed doesn't matter there, and 
>   often negative values are useful to indicate errors. 
> 
> * Use _signed_ for stride values, they are a "relative" value and might
>   become negative.

yep.

> * For hacks which use bit-patterns etc. to speed up calculation, use 
>   "sizeof()", or define plattform dependent macros in portab.h 

i dont follow. can u elaborate chirstoph?

-- pete; life is like a box of ammo