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