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.
Hi, I am using ARM 2478 with keil/Real View Compiler. code to test the problem..
#include <LPC24xx.H> /* LPC23xx/LPC24xx definitions */ #include <stdlib.h> #include <stdio.h> #include <string.h> int main (void) { unsigned char *ptest; int *ptest2; int *nIntVector; unsigned char *ncVector; int nLocInt; size_t k, nVecLen; unsigned char *pByte; // // nVecLen = 2 * sizeof(int); //nIntVector = (int *)calloc(2,nVecLen); //ncVector = calloc(2,nVecLen); ncVector = malloc(2*nVecLen); // // Fill memory with 0x00, 0x01, 0x02….., 0x07 pByte = (unsigned char *)ncVector; for (k=0; k<nVecLen; k++) *(pByte++) = (unsigned char)k; // ptest = (unsigned char *)ncVector; *ptest++; nIntVector = (int *)ptest; nLocInt = *nIntVector; }
So the malloc start at address 0x40000010 in this example. the loop i have writes data 0 to 7 consecutively starting from address 0x40000010. Address 0x40000010 should have value 0x00 Address 0x40000011 should have value 0x01 Address 0x40000012 should have value 0x02 Address 0x40000013 should have value 0x03 Address 0x40000014 should have value 0x04 Address 0x40000015 should have value 0x05 Address 0x40000016 should have value 0x06
Ok now the problem is if the pointer nIntVector is pointing to address 0x40000011 and i am trying to retrieve the int value shoundt nLocInt be 0x04030201?? But instead i get 0x00030201... whats going on? Thanks
__packed int *nIntVector; ... nIntVector = (__packed int*)ptest;
Should do it. Not very efficiently, though.
-- Marcus http://www.doulos.com/
Should do it.
That wording might be mistaken as meaning that that's what the OP should do. What he really should is not go near that with a 10-foot pole unless there's an utterly compelling reason for it. I massively doubt there is.
Thanks for the replies guys..I appreciate it. I looked more into the Memory Alignment issues for ARM architure, and i seem to understand what is going on. But we have this giant buffer parser written in C for x86, so we have to if it is efficient to this the packed attribute or redesign parts of parser..
Thanks, Nav
When working with byte arrays, I normally write macros or inline functions for get8(), get16(), get32() etc just to isolate the business logic from needing to care about target hardware issues.
Remember that a byte array may just as well have the integers in reversed byte order. No pack instruction will help you solve that problem.
Does the data in ncVector comprise of only 32 bit values? In that case, you might want to allocate it either statically and align it explicitly, or you malloc a buffer of size (2 * sizeof(int) + 3) and use a second pointer
nVecLen = 2 * sizeof(int) + 4; ... ncVector_aligned = (ncVector + 4) & ~3;
as byte array. Replace magic numbers with sizeof magic if you like. Do not use __packed in this case and keep your fingers crossed. This way you will trick the compiler, but you know that data will be word aligned.
Keep ncVector, though, for freeing up heap again. Put an assertion in your code and document everything carefully.
Regards Marcus http://www.doulos.com/arm/
I mean
nVecLen_aligned = 2 * sizeof(int) + 3;
In your loop you'd still use nVecLen. -- Marcus
Note that depending on allocation system, you should not need to worry. malloc() should give (requirement of the standard) proper alignment for any object or array of objects. So with malloc(), there shouldn't be a need to play with manual align corrections unless there is also a requirement to align with a cache line.
And lastly <slap forehead> you could malloc() an integer array and cast it to char of course.
-- Marcus