Enforcing pointer alignment

Manu,

See this article: http://processors.wiki.ti.com/index.php/Pragmas_You_Can_Understand .  There is a specific example that talks about using the _nassert intrinsic to do something similar.

Regards,

Dan

Hi Dan,

That article only explains how to rename existing pragmas, including _nassert. I am not looking to use _nassert. It is only a hint to the compiler, which is useful in my case only when I am already sure that a pointer is aligned, and I want the compiler to know this. Instead, the kind of functionality I want is more like assert, where I can check at runtime (or even compile time) that a given pointer is actually aligned. I was hoping there was a mechanism more efficient than using asserts, and something that one could also use in production code.

Manu

Manu,

I went back and reread the documentation on the _nassert macro.  I had misunderstood it's purpose.  I thought it worked like  an assert. 

As I think you alluded to, Assertions can't be used in production code because they essentially just abort the application and print stuff to stdout. 

One of the roadblocks to the compiler being able to detect whether your pointer is aligned or not aligned on a  double word boundary is that the location of the buffer hasn't been defined until the linker assigns it to a memory location.  But this doesn't happen until compilation is finished.  This is the reason for the DATA_ALIGN pragma.  The compiler is telling the linker "I expect this data to be aligned on a specified boundary", so if you can't align it that way, generate an error.  So, the linker will tell you if it for some reason (not enough space in output section) cannot align the data to the specifications. 

One of the other points you brought up:

>>There are ways to create an aligned buffer, but what if I forget to put that pragma, or advance my pointer by an odd amount?

Is forgetting to put the pragma in more likely than forgetting to check for alignment?  You could think of a #pragma DATA_ALIGN as an ASSERT(Buffer Is Aligned) statement.  Also, if you want help from the compiler, you should only directly access data elements in this buffer through doubleword pointers, and allow the compiler to do the arithmetic for you.  When you build with optimization on, the optimizer will condense this down into the most efficient accesses (this is where _nassert may be useful). 

I can understand the desire to check all of these things at runtime, but, to do so will require CPU cycles.  So, the better option is to let the compiler and optimizer do the work for you by guaranteeing that the buffer is aligned and handling any non doubleword accesses.

Regards,
Dan

Dan,

That makes sense. I was reading about alignment traps on the ARM architecture and thought something similar might exist on this one too. You raise a valid point of forgetting to check for alignment in the consuming function itself, but in modular development, it is less likely to happen than losing track of buffers being fed to the function itself. This will be especially true if buffers are being created dynamically, in which case, pragma's won't even be an option.

For now, I am just using asserts or similar macros that I can retain even in a Release build if so desired. I believe it will be possible to ensure exactly the same buffer allocations by the linker with and without asserts built in, if data sections used by asserts can be separated out so that they won't affect rest of the allocations. Then I can safely remove asserts after testing. (Of course, this is true only for statically allocated buffers). Does that sound reasonable?

Thanks,
Manu 

Yeah, I think it does.  For Debug Purposes, you can do exactly what you said before, as you don't care so much about cycles as you do on your deployed application.  You can create a macro that does the check that you were suggesting, and then undefine the macro for your release build. 

If you are dynamically allocating buffers, say using malloc(), you can guarantee that the buffer will be aligned on a doubleword boundary if you use a doubleword pointer. You just need to compensate for this when you are specifying the number of locations to allocate.   Structures are the same way.  A structure will always be aligned on a boundary the size of it's largest element.  

Regards,
Dan