• Locked Locked
  • Replies 3 replies
  • Subscribers 119 subscribers
  • Views 3043 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

typecast arm problem

axesnetwork
Note: This was originally posted on 29th July 2009 at http://forums.arm.com

Hi


I use eclipse+yagarto+the exemple getting-started-project-1.3-at91sam7x-ek or RTOS "ARM7_AT91SAM7X256_Eclipse". I have a problem when I do this
char var1[2];
int short var2 = 0x1234;

*(int short*)var1 = var2

When I do the typecast the arm stop working if the address is odd. Can you tell me why the arm his not able to do that and how I can solve my problem, because with the Rabbit I was able to do that. I know I can use memcpy, but with this cast I save some CPU time.
  • Arm Employee Badge
    Note: This was originally posted on 29th July 2009 at http://forums.arm.com

    This isn't valid C code - which is why it breaks.

    The C compiler will (correctly) assume natural alignment of types and generates load and store instructions accordingly. In your case the compiler will generate LDRH and STRH (load and store halfword) instructions when accessing the buffer through the "short" pointer - but these instructions are not valid if the memory is only byte aligned. You will get a data abort in this case.

    You have a few choices:

    (1) You can use a compiler-specific extension to mark the memory buffer as packed (which will cause an ARM7 to generate byte loads and assemble the result).

    (2) Memcpy - which is probably as fast as the above anyway because compilers are pretty good at optimizing short copies. And it's portable across multiple compilers because it is compliant C code.

    (3) Ensure data is properly aligned in the first place - which is typically the highest performance solution.

    Later ARM cores, such as ARM11 and Cortex-A include unaligned load /store support, so your example will work. However, you still have to be aware that the code is not really valid C and as such is prone to portability issues.
  • Arm Employee Badge
    Note: This was originally posted on 30th July 2009 at http://forums.arm.com

    I should have mentioned that the memcpy route is often as fast as the aliased pointer route if the compiler has been told it is OK to generate unaligned accesses.

    If you are on a CPU with unaligned access support enabled "memcpy" of a small variable is often converted to a single unaligned load - compilers are very good at optimizing small memcpy accesses because they are so common in compliant C code.
  • Note: This was originally posted on 30th July 2009 at http://forums.arm.com

    When I do the typecast the arm stop working if the address is odd. Can you tell me why the arm his not able to do that and how I can solve my problem, because with the Rabbit I was able to do that. I know I can use memcpy, but with this cast I save some CPU time.


    Yes, in fact it is safer to avoid the optimization and use memcopy itself. We actually ran into a lot of trouble because we used this optimization. Initially we were working on Cortex M3 which supports unaligned access but later we had to port it to ARM7TDMI and then all hell broke loose. We had a really bad time trying to find each and every place where we had used this kind of typecast and replacing them with memcopys - so i'd suggest, use the time tested memcopy [:)]