[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] Re: Porting to ARM



Bjorn Wesen wrote:

> On Tue, 26 Sep 2000, Erwin Authried wrote:
> > The only problem is the rather bad optimization with big-endian cpus
> > that don't allow misaligned access (ARM). When a >=2 byte value
> > is read, it is first assembled by reading/shifting the byte values in the
> > cpu's byte order, finally the bytes need to be swapped again to get
> > the opposite byte order. I'm not sure, but I believe it's done that way.
>
> The swap is usually a single instruction, and an "unneeded" extra
> instruction compared to the performance hit of an unaligned load (or
> compared to the relatively slow bitrate of bluetooth itself even) is
> Mostly Harmless..
>
> -Bjorn

Just to clarify, what your're suggesting is this:
1. Use the packed attribute to solve alignment problems (ok, that seems to
work).
2. Use ntohl & friends to solve the endian problems. So, for example:

        foo = buf;
        foo->u16field = 0xa5a5;
        htons(foo->u16field)          /* add this line? */

    I guess I could look at ntohl/s to see which one is for 2 bytes. Hopefully
that isn't architecture-dependent.
3. For 12, 6 and other length bitfields use an endian-safe macro to do the
shifting?

--Gordon