[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