This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: ARM7 problem with ldr assembly instruction


Gary, thanks a lot!
I'll use your suggestions.
I know it is not your call but wouldn't be logical to assume at least core
exception in such case (abort) like Motorola had once rather then the
instruction
that doesn't do anything :-(
I'll try to ask ARM and will post the answer if it will be any :-)

> -----Original Message-----
> From: Gary Thomas [mailto:gary@chez-thomas.org]
> Sent: Friday, July 12, 2002 10:34 AM
> To: benny@voicepump.com
> Cc: Ecos-Discuss (E-mail)
> Subject: Re: [ECOS] ARM7 problem with ldr assembly instruction
>
>
> On Fri, 2002-07-12 at 11:19, benny wrote:
> > I have c-code, where the register should get 32-bit value from the
> > memory, which happens to be not 32-bit aligned (16-bit aligned).
> > The C-line looks like:
> > ip_address.s_addr = ((UDP_CONNECT_T*)data_ptr)->ip_address;
> > and ip_address is not on 32-bit boundary.
> >
> > My compiler 2.95.2 for ARM generates instruction:
> >
> > ldr r1, [r11, -#102]
> >
> > What a surprise - this instruction doesn't do anything !!!
> > the contents of r1 didn't change !!!
> >
> > If the address is 32-bit aligned, then everything works fine.
> > There are no warnings neither from compiler, nor from the
> execution module
> > (like abort).
> >
> > My question:
> > is this a ARM core bug, specific processor bug (I use Samsung C4510),
> > compiler
> > bug or my own bug.
> > If ldr doesn't allow not-aligned access, then how is it
> possible to avoid
> > such
> > conditions in the code?
> >
>
> It depends on the ARM core, but most do not support unaligned
> operations.
>
> How to make sure things are aligned?
>   * First, use the correct data size.  'long' and 'int' should be forced
>     by the compiler to be 32 bit aligned.
>   * Most alignment problems happen when you cast things to different
>     size operands.  If you need to do this, then use a function which
>     operates on small pieces and reconstructs, rather than trying to
>     just "cast" your way out of it.  e.g. instead of
>        *(int *)&a
>     use
>        (((short *)&a)[1] << 16) | (((short *)&a)[0] << 0)
>     The one concern here is to make sure you preserve the endian-ness
>     of the accesses.
>
> > It is not eCOS specific question (may be tool question) but may
> be somebody
> > here
> > know the answer?
> >
> > Regards,
> > Benny
> >
> >
> > --
> > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]