[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OpenDivX] Strange problems on the ARM platform

> And how could I track this down ? What are the different 'stages' where I
> could hook-up some debug code that could dump the memory to see exactly
> where the corruption occurs ? I already tried to dump all the memory

maybe it's related to the following? (found it on handhelds.org wiki)
e.g. this would mean that CopyBlock wouldn't work correctly for all
possible inputs of Src and Dst (i'm assuming copies can be from/to
arbitrary x,y locations, but it is a guess) when doing the copy with

**Pointer Alignment Issues**

On many CPU architectures, the memory system requires that loads of
values larger than one byte
must be properly aligned. Usually, this means that a 2-byte quantity
must be aligned on an even
address boundary, a 4-byte quantity must be aliged on a multiple of 4
boundary and sometimes
8-byte quantities must be aligned to addresses that are a multiple of 8.
Depending on the CPU
and the operating system, misaligned loads and stores may cause a
signal, may be handled in the
OS, or may be silently rounded to the appropriate boundary.

The x86 boundary imposes no such alignment restriction, so some programs
written for the x86
do not use the proper alignment for other architectures.

ARM Linux defaults to silently round the address to the appropriate
alignment boundary. This
can even be a feature, because it lets you rotate values by storing and
loading with different
pointer alignments. (But isn't there a rotate instruction that would
execute faster?)

OpenDivX mailing list
[email protected]

Reply To Poster

Local References / HOW-TO / FAQs