[x264-devel] unaligned accesses in IA64

Nestor ncfernan at gmail.com
Thu Feb 28 19:26:49 CET 2008


Hi Mauricio,

I guess there is a bit of confusion here. The pointer is used, as the name
suggests, to point to some place where you can peek or poke information. The
contents of the pointer can receive any value, so the compiler cannot be
used to force alignment on its contents.

In the case you are showing, you are loading a "number" (which happens to be
an address) that is not divisible by 64, as you pointed out. When your code
tries to use that pointer the processor complains, usually throwing an
exception that would take forever to discover what you are trying to do and
working around the problem.

So, you cannot instruct the compiler to fix the pointer value. The address
it's taking is from a unaligned structure, there is nothing you can do
unless you "unpack" that structure.

BUT you can use a neat trick that allows you to read and write to unaligned
addresses without the penalty associated with an exception handling by the
Operationg System.

I'll show you how to do it for 32 bits and you can extend further to 64
bits.

file.h:

//==========================================
typedef union { u32 dw;
                u16 w[2];
                u8  u[4];
              } T_DWORD;
//==========================================
typedef union { u16 w;
                u8  u[2];
              } T_WORD;
//==========================================
u16 READ_UNALIGNED_16(const u8 *p);
u32 READ_UNALIGNED_32(const u8 *p);
//==========================================
void WRITE_UNALIGNED_16(u8 *p, u16 value);
void WRITE_UNALIGNED_32(u8 *p, u32 value);
//==========================================


file.c:

//==========================================
u32 READ_UNALIGNED_32(const u8 *p)
{
  T_DWORD n;

  n.u[3] = p[3];
  n.u[2] = p[2];
  n.u[1] = p[1];
  n.u[0] = p[0];

  return (n.dw);
}
//==========================================
void WRITE_UNALIGNED_32(u8 *p, u32 value)
{
  T_DWORD d;

  d.dw = value;

  p[0] = d.u[0];
  p[1] = d.u[1];
  p[2] = d.u[2];
  p[3] = d.u[3];
}
//==========================================


I hope this helps.

(Nestor)



On Thu, Feb 28, 2008 at 1:49 PM, Mauricio Alvarez <lokifo at gmail.com> wrote:

> Hi,
>
> On Thu, Feb 28, 2008 at 2:16 PM, Loren Merritt <lorenm at u.washington.edu>
> wrote:
> > On Tue, 26 Feb 2008, Mauricio Alvarez wrote:
> >  > x264(8689): unaligned access to 0x607fffffff32ee5c,
> ip=0x40000000000afb71
> >  > x264(8689): unaligned access to 0x607fffffff32ee64,
> ip=0x40000000000aff31
> >
> >  The obvious step is to disassemble it and see what pieces of code
> >  correspond to addresses 0x40000000000afb71 and 0x40000000000aff31.
>
>
> I repetead the test with the following configuration: gcc with -01 -g
> (--enable-debug). Using different input videos and different number of
> frames to encode I found the following unaligned accesses:
> x264(11582): unaligned access to 0x607ffffffece29ac, ip=0x400000000005d901
> x264(11582): unaligned access to 0x607ffffffece29b4, ip=0x400000000005dd50
> x264(11582): unaligned access to 0x607ffffffece29ac, ip=0x400000000005d2b1
> x264(12585): unaligned access to 0x607ffffffeac69cc, ip=0x400000000005d2f0
> x264(12585): unaligned access to 0x607ffffffeac69ac, ip=0x400000000005cb00
> x264(12585): unaligned access to 0x607ffffffeac69b4, ip=0x400000000005cb20
> x264(12585): unaligned access to 0x607ffffffeac69b4, ip=0x400000000005d2d1
>
> the most common one is: x264(11582): unaligned access to
> 0x607ffffffece29b4, ip=0x400000000005dd50
>
> All these accesses correspond to stores to the mvc array in
> x264_mb_analyse_inter_XXX functions in analyse.c . The problem is that
> the base address that these functions are receiving is not 64-bit
> aligned.
> Just an example from the function x264_mb_analyse_inter_p8x8():
>
> // initialization of mvc
> //encoder/analyse.c:1100
>    int (*mvc)[2] = a->l0.mvc[i_ref];
>
> // access to mvc
> //encoder/analyse.c:1107
> *(uint64_t*)mvc[0] = *(uint64_t*)a->l0.me16x16.mv;
> 400000000005d8f6:       f0 00 84 08 42 00                   adds
> r15=512,r33;;
> 400000000005d8fc:       00 00 04 00                         nop.i 0x0
> 400000000005d900:       0b 78 00 1e 18 10       [MMI]       ld8
> r15=[r15];;
>
> // access to mvc
> //encoder/analyse.c:1127
> *(uint64_t*)mvc[i_mvc] = *(uint64_t*)m->mv;
> 400000000005dd40:       0b 70 00 40 01 21       [MMI]       adds
> r14=128,r32;;
> 400000000005dd46:       e0 00 38 30 20 00                   ld8 r14=[r14]
> 400000000005dd4c:       00 00 04 00                         nop.i 0x0;;
> 400000000005dd50:       02 40 38 56 98 15       [MII]       st8
> [r43]=r14,8
>
> I'm not familiar with the X264 code, so I ask this: it is possible to
> force (by using a compiler directive) a specific alignment  to these
> pointers? Or are there generated dynamically by motion estimation?.
>
> Regards,
>
> Mauricio A.
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20080228/9051c27c/attachment.htm 


More information about the x264-devel mailing list