On Dec 12, 2007 6:27 PM, Nuno Lucas <[EMAIL PROTECTED]> wrote:
> > 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...
This isn't the actual code, just an approximation, and we do use it.
It can be e.g. amount of HP lost by the player.
>
> > 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.
>
>
> 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).
>
In that sad case, I'll leave the code as it is.
>
> Just my .02€,
Very worthy 2 eurocents, I must say ;)
--
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
