public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Acess unaligned address
@ 2001-04-09 22:27 james chen
  2001-04-10 13:18 ` Jonathan Larmour
  0 siblings, 1 reply; 3+ messages in thread
From: james chen @ 2001-04-09 22:27 UTC (permalink / raw)
  To: ecos-discuss

Hello, When I debug example on my test board ( based on ARM7TDI), run into
__unpack_f function. it will stop at the instruction "ldr r3, [r0,
2]"( r0's value is word aligned ) and report bus error. I think that CPU has
access unaligned adress(see below document, get it from web page). so what
can I do to avoid it.

Regards,
james

===================================================
__unpack_f is a function .../gcc/config/fp-bit.c
0c00eb18 <__unpack_f>:
 c00eb18: e1a0c00d  mov r12, sp
 c00eb1c: e92dd800  stmdb sp!, {r11, r12, lr, pc}
 c00eb20: e590e000  ldr lr, [r0]
 c00eb24: e5d02003  ldrb r2, [r0, #3]
 c00eb28: e24cb004  sub r11, r12, #4 ; 0x4
 c00eb2c: e5903002  ldr r3, [r0, #2]    =============> cause bus error
 ...................................

===========================================================
Unaligned LDR for accessing halfwords

In some circumstances the ARM compilers can intentionally generate unaligned
LDR instructions. In particular the compiler will do this to load halfwords
from memory. This is because by using an appropriate address the required
halfword can be loaded into the top half of a register and then shifted down
to the bottom half. This requires only one memory access whereas doing the
same operation using LDRB's would require two memory accesses, plus
instructions to merge the two bytes. On ARM architecture v3 and earlier this
will typically be done for any halfword loads. On Architecture v4 and later
this will be done less often because dedicated halfword load instructions
exist, but unaligned LDRs may still be generated - for instance to access an
unaligned short within a packed structure.

Note that such unaligned LDRs will only be generated by the ADS compilers if
you enable them using the '-memaccess +L41' option.

[Note that for SDT 2.5x, the compiler will generate such loads by default.
They can be disabled using the '-za1' compiler option.]

Porting code and detecting unaligned accesses

Legacy C code for other architectures (e.g. x86 CISC) may perform accesses
to unaligned data using pointers which will not work on the ARM. This is
non-portable code - such accesses must be identified and corrected to work
on RISC architectures which expect aligned data.

Identifying the unaligned accesses can be difficult, because use of load or
store with unaligned addresses will give incorrect behavior. But it will be
difficult to trace which part of the C source is causing the problem.

ARM processors with full MMUs (e.g. ARM920T) support optional alignment
checking where the processor will check every access to ensure it is
correctly aligned. The MMU will raise a data abort if an incorrectly aligned
access occurs.

Some ARM partners using simple cores such as the ARM7TDMI have implemented
alignment-checking for their ASIC/ASSP. This can be done with an additional
hardware block external to the ARM core, which monitors the access size and
the least significant bits of the address bus for every data access. The
ASIC/ASSP can be configured to raise the ABORT signal in the case of an
unaligned access. ARM recommends that such logic is included on ASIC/ASSP
devices where code will be ported from other architectures.

If the system is configured to abort on unaligned accesses, a data abort
exception handler should be installed. When an unaligned access occurs, the
data abort handler will be entered - this can identify the erroneous data
access instruction which is located at (r14-8).



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [ECOS] Acess unaligned address
  2001-04-09 22:27 [ECOS] Acess unaligned address james chen
@ 2001-04-10 13:18 ` Jonathan Larmour
  2001-04-10 18:36   ` james chen
  0 siblings, 1 reply; 3+ messages in thread
From: Jonathan Larmour @ 2001-04-10 13:18 UTC (permalink / raw)
  To: james chen; +Cc: ecos-discuss

james chen wrote:
> 
> Hello, When I debug example on my test board ( based on ARM7TDI), run into
> __unpack_f function. it will stop at the instruction "ldr r3, [r0,
> 2]"( r0's value is word aligned ) and report bus error. I think that CPU has
> access unaligned adress(see below document, get it from web page). so what
> can I do to avoid it.

From the gcc manual:

`-malignment-traps'
     Generate code that will not trap if the MMU has alignment traps
     enabled.  On ARM architectures prior to ARMv4, there were no
     instructions to access half-word objects stored in memory.
     However, when reading from memory a feature of the ARM
     architecture allows a word load to be used, even if the address is
     unaligned, and the processor core will rotate the data as it is
     being loaded.  This option tells the compiler that such misaligned
     accesses will cause a MMU trap and that it should instead
     synthesise the access as a series of byte accesses.  The compiler
     can still use word accesses to load half-word data if it knows
     that the address is aligned to a word boundary.

     This option is ignored when compiling for ARM architecture 4 or
     later, since these processors have instructions to directly access
     half-word objects in memory.

IIRC what we do on all our ARM ports is disable MMU alignment traps. If you
want to enable them, you will need to rebuild gcc, and edit
gcc/config/t-arm-elf to add either a multilib for -malignment-traps, or if
you don't mind making the tools completely this way, just add
-malignment-traps to TARGET_LIBGCC2_CFLAGS

One thing I'm slightly confused about is that libgcc _should_ have
defaulted to bulding for the arm7tdmi, which is a V4 architecture I
believe.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [ECOS] Acess unaligned address
  2001-04-10 13:18 ` Jonathan Larmour
@ 2001-04-10 18:36   ` james chen
  0 siblings, 0 replies; 3+ messages in thread
From: james chen @ 2001-04-10 18:36 UTC (permalink / raw)
  To: Jonathan Larmour; +Cc: ecos-discuss

Hello, Jifl:
   I am sorry that I make a mistake. I use the wrong CPU(arm7di) instead of
arm7tdmi in my make file, so it cause error.Now it works well.
thank you very much!
Best Regards,
james

> james chen wrote:
> >
> > Hello, When I debug example on my test board ( based on ARM7TDI), run
into
> > __unpack_f function. it will stop at the instruction "ldr r3, [r0,
> > 2]"( r0's value is word aligned ) and report bus error. I think that CPU
has
> > access unaligned adress(see below document, get it from web page). so
what
> > can I do to avoid it.
>
> From the gcc manual:
>
> `-malignment-traps'
>      Generate code that will not trap if the MMU has alignment traps
>      enabled.  On ARM architectures prior to ARMv4, there were no
>      instructions to access half-word objects stored in memory.
>      However, when reading from memory a feature of the ARM
>      architecture allows a word load to be used, even if the address is
>      unaligned, and the processor core will rotate the data as it is
>      being loaded.  This option tells the compiler that such misaligned
>      accesses will cause a MMU trap and that it should instead
>      synthesise the access as a series of byte accesses.  The compiler
>      can still use word accesses to load half-word data if it knows
>      that the address is aligned to a word boundary.
>
>      This option is ignored when compiling for ARM architecture 4 or
>      later, since these processors have instructions to directly access
>      half-word objects in memory.
>
> IIRC what we do on all our ARM ports is disable MMU alignment traps. If
you
> want to enable them, you will need to rebuild gcc, and edit
> gcc/config/t-arm-elf to add either a multilib for -malignment-traps, or if
> you don't mind making the tools completely this way, just add
> -malignment-traps to TARGET_LIBGCC2_CFLAGS
>
> One thing I'm slightly confused about is that libgcc _should_ have
> defaulted to bulding for the arm7tdmi, which is a V4 architecture I
> believe.
>
> Jifl
> --
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
>
>


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2001-04-10 18:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-04-09 22:27 [ECOS] Acess unaligned address james chen
2001-04-10 13:18 ` Jonathan Larmour
2001-04-10 18:36   ` james chen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).