[FFmpeg-devel] [PATCH] Make HAVE_FAST_UNALIGNED allow unaligned memory accesses

[Michael Niedermayer]

On Tue, Jul 15, 2008 at 08:16:21PM +0100, Mans Rullgard wrote:
> If HAVE_FAST_UNALIGNED is defined, potentially unaligned data is
> accessed through normal pointers.  Otherwise, compiler-specific
> code is used to perform unaligned accesses, falling back to
> byte-wise access if no compiler support is available.
> ---
>  libavutil/intreadwrite.h |  130 +++++++++++++++++++++++++++------------------
>  1 files changed, 78 insertions(+), 52 deletions(-)

[...]

> @@ -37,7 +39,19 @@ struct unaligned_16 { uint16_t l; } __attribute__((packed));
>  #define AV_WN32(a, b) (((struct unaligned_32 *) (a))->l) = (b)
>  #define AV_WN64(a, b) (((struct unaligned_64 *) (a))->l) = (b)
>  
> +#elif defined(__DECC)
> +
> +#define AV_RN16(a) (*((const __unaligned uint16_t*)(a)))
> +#define AV_RN32(a) (*((const __unaligned uint32_t*)(a)))
> +#define AV_RN64(a) (*((const __unaligned uint64_t*)(a)))
> +
> +#define AV_WN16(a, b) *((__unaligned uint16_t*)(a)) = (b)
> +#define AV_WN32(a, b) *((__unaligned uint32_t*)(a)) = (b)
> +#define AV_WN64(a, b) *((__unaligned uint64_t*)(a)) = (b)

This change is ok, as a seperate commit (note ive edit it, the removial
of #else on its own would break the code).

The rest of the patch has to be split in cosmetics that are free of
functional changes and the functional changes before it is reviewable.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080716/e65715c7/attachment.pgp>