Unaligned memory access through pointer in cortex-m3

Hi friends,
I am using stellaris LM3s6965 micro-controller, Keil (MDK-ARM 4.20) as
IDE.

I want to know the alignment restrictions on using pointer of
following type.

Uint8_t * (unsigned char 8-bit)
Uint16_t * (unsigned 16-bit)
Uint32_t * (unsigned 32-bit)

 I need to access 32-bit or 16-bit data from a memory buffer. There is
no guarantee that address will be aligned. In this case what should I
do?


Thanks & regards,
Kishore.

On 09/18/2011 02:03 PM, kishor wrote:
>
> Hi friends,
> I am using stellaris LM3s6965 micro-controller, Keil (MDK-ARM 4.20) as
> IDE.
>
> I want to know the alignment restrictions on using pointer of
> following type.
>
> Uint8_t * (unsigned char 8-bit)
> Uint16_t * (unsigned 16-bit)
> Uint32_t * (unsigned 32-bit)
>
>   I need to access 32-bit or 16-bit data from a memory buffer. There is
> no guarantee that address will be aligned. In this case what should I
> do?

I'm not familiar with the LM3s6965, but the Cortex-M3 core allows 
unaligned accesses. It does have the option to generate a fault on such 
an access, so you have to make sure this is disabled (this is the 
default after a reset)

For best performance, you'd want to use aligned accesses as much as 
possible, though.

On Sep 18, 5:03=A0am, kishor <kiis...@gmail.com> wrote:
> Hi friends,
> I am using stellaris LM3s6965 micro-controller, Keil (MDK-ARM 4.20) as
> IDE.
>
> I want to know the alignment restrictions on using pointer of
> following type.
>
> Uint8_t * (unsigned char 8-bit)
> Uint16_t * (unsigned 16-bit)
> Uint32_t * (unsigned 32-bit)
>
> =A0I need to access 32-bit or 16-bit data from a memory buffer. There is
> no guarantee that address will be aligned. In this case what should I
> do?
>
> Thanks & regards,
> Kishore.

Declare the buffers as 32 bits array.  The compiler should take care
of the alignment.

kishor wrote:
> I need to access 32-bit or 16-bit data from a memory buffer. There is
>no guarantee that address will be aligned. In this case what should I
>do?

Why "there is no guarantee"?  Do you have control on how these buffers
are defined/created?

If they are "malloced", they should be aligned properly for all
built-in data types.

If they are defined explicitly, tricks like this will assure proper
alignment:

union align32
{
	Uint32_t anchor;
	Uint8_t  buffer8[???];
	Uint16_t buffer16[???];
};

Your compiler may provide something like "#pragma align" to do the
same, (I'm not familiar with Keil tools), or a #pragma to control what
memory section is used for the buffers, and then the alignment for
that section can be specified in the linker configuration file.

If none of the above is doable, you can just take a performance hit
when accessing unaligned 16/32-bit data.  

Lastly, if you need the code to be portable to architectures that will
not allow unaligned memory accesses, write read_u16(...) /
write_u16(...) / read_u32(...) / write_u32(...) functions working on
8-bit values only.
--
Roberto Waltman

[ Please reply to the group,
  return address is invalid ]

Thanks for quick replies.

> Why "there is no guarantee"? =A0Do you have control on how these buffers
> are defined/created?

The buffer is 8-bit array of 512 bytes. It contains data protocol
mixed with 8-bit & 16-bit data types.
so all data access can not be aligned.

Method -1
                  Disable the unaligned access fault
                  Read unaligned data from buffer
                  Enable the unaligned access fault

Did disable/enable "unaligned access fault" process takes time?

Method - 2
                 Read multiple 8-bit data through 8-bit pointer
                 Pack them to 16-bit or 32-bit variable

Which is the better option for efficiency & performance.
I don't want to port this code outside of cortex-m3.

Thanks & regards,
Kishore.

Thanks for quick replies.

> Why "there is no guarantee"?  Do you have control on how these buffers
> are defined/created?

The buffer is 8-bit array of 512 bytes. It contains data protocol
mixed with 8-bit & 16-bit data types.
so all data access can not be aligned.

Method -1
                  Disable the unaligned access fault
                  Read unaligned data from buffer
                  Enable the unaligned access fault

Did disable/enable "unaligned access fault" process takes time?

After disabling the unaligned memory access fault, will its
performance affects on aligned memory access too?
If not then I can disable the fault at reset. I will try aligned
memory access as much as possible.

Method - 2
                 Read multiple 8-bit data through 8-bit pointer
                 Pack them to 16-bit or 32-bit variable

Which is the better option for efficiency & performance.
I don't want to port this code outside of cortex-m3.

Thanks & regards,
Kishore.

> The buffer is 8-bit array of 512 bytes. It contains data protocol
> mixed with 8-bit&  16-bit data types.
> so all data access can not be aligned.
>
> Method -1
>                    Disable the unaligned access fault
>                    Read unaligned data from buffer
>                    Enable the unaligned access fault
>
> Did disable/enable "unaligned access fault" process takes time?

Enabling/disabling the fault only takes a single write to a register, so 
it's negligible. You could also leave it disabled all the time, as long 
as you pay attention to the alignment of your other variables.

> Method - 2
>                   Read multiple 8-bit data through 8-bit pointer
>                   Pack them to 16-bit or 32-bit variable
>
> Which is the better option for efficiency&  performance.
> I don't want to port this code outside of cortex-m3.

Unaligned reads are going to be faster than single byte reads and 
assembling the data yourself.

In some cases there are some other options, such as copying a block of 
data to align all its variables at the same time. Of course, this only 
works if all variables inside the block are mis-aligned in the same way. 
This may be combined with CRC calculations and/or copying the headers to 
faster memory.

Thanks Arlet Ottens.