RE: [ECOS] Problem with unaligned memory access on ARM920T

["Robert Cragie" <rcc at jennic dot com>]

The ARM920T is a RISC processor. RISC processors generally do not allow word
accesses on anything but a word-aligned boundary - it will not work out that
it has to do an additional fetch to produce the word unlike some processors
(e.g 68030, 80x86), therefore it is no surprise to me that it simply
substitutes what it sees on the bus. As there is no address error exception
like on, say, the 68000, your code will not actually throw an exception but
just do something less than predictable.

The sort of code you have written is dangerous and non-portable and I would
not recommend it unless you are just experimenting. You should only access
words on word-aligned boundaries and halfwords on halfword-aligned
boundaries. Only byte accesses can be guaranteed at any address. Most
compilers will pad and align structures accordingly to ensure this happens,
although in some instances it is possible to override this using 'packed'
directives. However, if you do this, you often have to access the members
using byte accesses.

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655
_______________________________________________________________

> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Chaitanya
> Huilgol
> Sent: 22 August 2003 11:02
> To: ecos-discuss@sources.redhat.com
> Subject: [ECOS] Problem with unaligned memory access on ARM920T
>
>
> Hello
>
> I am facing problems due to unaligned memory access on the
> ARM920T procesor,
> using the arm-elf-gcc compiler.
> Here is the example code which produces unsusal results :
>
>     unsigned long  ar_l[2];
>     char ar_c[6]={0xaa,0xbb,0xcc,0xdd,0xee,0xff};
>     char *p_c = ar_c;
>
>     ar_l[0]= *((unsigned long*)(p_c));
>     ar_l[1]= *((unsigned long*)(p_c+2));
>
> I was expecting the contents of ar_l to be :
>
> 0xaa,0xbb,0xcc,0xdd,0xcc,0xdd,0xee,0xff
>
> But i found it to be :
>
> 0xaa,0xbb,0xcc,0xdd,0xcc,0xdd,0xaa,0xbb
>
>
> why do the first 2 Byte's 0xaa,0xbb  get coiped instead of 0xee,0xff ?
>
>
> Thanks & Regards
> Chaitanya
>
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>
>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss