Forgot to CC: the list, again...
---------- Forwarded message ---------- From: Nuno Lucas <[EMAIL PROTECTED]> Date: Dec 12, 2007 5:26 PM Subject: Re: [Cegcc-devel] [Mingw32ce] Issues when casting char* => uint32_t* and using the [] operator To: Ivan Vucica <[EMAIL PROTECTED]> On Dec 11, 2007 8:32 PM, Ivan Vucica <[EMAIL PROTECTED]> wrote: > On Dec 11, 2007 7:48 PM, Nuno Lucas <[EMAIL PROTECTED]> wrote: > > > > > > http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable-Attributes > > > > Don't know how I forgot to include that option, sorry. Probably too > > focused on portable code. > > > > > > Regards, > > ~Nuno Lucas > > > > Hi, > > I presumed it's something to do with __attribute__ however I am still > unable to isolate the one I need ;) > > The "aligned" would sound like what I want, but upon reading it > further, I'm confused. It's not something to be used with malloc(), > right? Our code does something like this (please allow for any > mistakes, this isn't "real" code) No, the aligned attribute would be used with the stack array on your example, but I now see your actual code doesn't use one. > > uint8_t getu8(char **p) { > uint8_t a = **p; > *p ++; > return a; > } > > uint16_t getu16(char **p) { > uint16_t a = **p + (*(*p+1) << 8); // please ignore endianess > *p +=2; > return a; > } I wouldn't trust the return value here, but you seem to not be using it, so... > void function() { > char *buffer, *p; > uint32_t *x; > > buffer = malloc(500); // theoretically aligned to 32-bits? > buffer[0] = 0; > buffer[1] = 5; > buffer[2] = 8; > buffer[3] = 1; > buffer[4] = 2; > buffer[5] = 95; > .... > buffer[499] = 13; > > p = buffer; // p is now aligned to 4 bytes, right? > getu8(&p); // now it's p%4 == 1, right? > getu16(&p); // now it's p%4 == 3, right? > > // so we're now pointing with p at the memory that we reached > after getting some data from the buffer > // the memory p points to is not aligned to 4 > // we do, however, need to use the numbers that follow as 32bit integers > > x = (uint32_t*)p; > x[0] = x[1] + x[2]; There's no way to make this work with gcc tricks. Your system has to know how to manage un-aligned accesses for this to work, which you can't know for sure on a WinCE device (it depends on the CPU features). The thing is that not all CPU's "raise" an exception when doing an un-aligned access. Some just return the wrong value and don't give any sign that something wrong occurred. The check of the pointer alignment before every read access would kill any performance, even on fast CPU's (and we are talking of 200MHz CPU's here). I would just go for the memcpy() aproach. It will allow the CPU to optimize the best it can the copy operation. > // it would be silly if we could not circumvent this crash with a > compiler feature > // which, if really necessary, would add some instructions before > accessing the element > // similar to those i mentioned in a mail from 19:38 CET > // and in such case use an alternative way to construct a valid > integer in the register > // (personally i'd be happy to live with additional instructions in > case they're optional) > } I would not be surprised if the memcpy() would be actually faster than any code generated by the compiler to check for bad alignment. One of the things compilers try to avoid is conditional jumps, because "branch prediction" is a costly operation. Using memcpy() there is no need to have a conditional jump, so code can actually run faster (this because the size is fixed, off course). Just my .02€, ~Nuno Lucas > If anyone would like to test the "actual" code we're discussing, SVN is here: > http://opentibia.svn.sf.net/svnroot/opentibia/yatc/trunk/ > The encryption code that causes crashes is in folder > net/encryption.cpp and I've added ugly #ifdef to make it memcpy() if > running on WINCE. The protocol we use (a reverse engineered protocol) > is designed the way that we receive a message size (2 bytes) and then > the XTEA encrypted message. Once decrypted, we have a message size (2 > bytes) then packet id (1 byte) then custom data, then again packet id, > then custom data, etc etc. Custom data varies in size and number of > components. > > > > -- > Ivan Vučica > > -- Croatia -- > ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
