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]

Acess unaligned address


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).




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