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

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

The bluetooth packets are big-endian, thus the ntoh* functions are not usable.
The macros cpu_to_le* and le*_to_cpu from the kernel headers seem 
to do the right job. Using some clever assember inline codes isn't 
necessary. The ARM compiler, at least, produces much better code
with the simple, architecture independent definitions together with 
packed variable access. That's because the optimizer fetches the bytes
in the needed order. With the assembler version, the optimizer has
no chance to do this because the assembler instructions "insist" on 
the byte swapping, and can't be optimized away.



-----Ursprüngliche Nachricht-----
Von:	Bjorn Wesen [SMTP:bjorn.wesen@xxxxxxx.com]
Gesendet am:	Mittwoch, 27. September 2000 01:30
An:	Gordon McNutt
Cc:	So@xxxxxxx.com
Betreff:	Re: [bluetooth-dev] Re: Porting to ARM

On Tue, 26 Sep 2000, Gordon McNutt wrote:
> > The swap is usually a single instruction, and an "unneeded" extra
> 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? */

Well really

foo->u16field = htons(0xa5a5);

If you look in a TCP/IP stack or anything that touches data that needs to
pass between platforms of different endianess, you'll see the above. 

And when you receive, you do 

	i = ntohs(foo->u16field);

(or whatever you want to do with the data)

This is portable and fine. But the key question is if Bluetooth is a
network-endian protocol! If it's not, you cannot use the standardized
htons/ntohs because they can only convert between the host format and the
network format (so it's either a swap or a no-op depending on the host
arch). Then you need something comparable that always converts to
little-endian order (network is big-endian) like the macros suggested in
this thread (and then you'd define these in a clever way perhaps with arch
dependant asm instructions).