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

[Gary Thomas <gary at mlbassoc dot com>]

On Fri, 2003-08-22 at 04:02, Chaitanya Huilgol wrote:
> 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 ?

Talk to ARM :-)  In general, such operations are not defined by the ARM 
architecture and you'll get differing results on different cores.  The
only way to get the results you are looking for is to set up to catch
the "unaligned" exception and then perform the actual [offending]
machine instruction in the trap handler.  Currently, eCos does not
do this - we've never seen the benefit [it's a lot of trouble for
a very rare situation.  e.g. the code in the Linux kernel which handles
this is over 600 lines of C, and it only handles the "load" case, not
"store"]

Why would you want to do this?  In the rare instance that we've
ever seen, it's much better to recognize that the condition exists
and then handle the unaligned transfer manually.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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