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

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



Bjorn,

you are right, gcc is really able to pack the structures in the
intended way, so this ugly #define stuff isn't needed.
The available macros/inline functions in the kernel headers
are able to do the necessary conversions (cpu_to_le*,cpu_to_be* ....).
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.
Therefore, I think that converting values between big/little endian is 
different from reading/writing values from/to a buffer, and should
deserve a seperate set of macros/inline functions. The optimum
solution for the embedded world would be a new gcc attribute to specify
the endianness of a variable, so that  you can specify that a variable is
always stored as BE or LE, indpendent of the cpu's endianness.

Regards,

Erwin

Bjorn Wesen[SMTP:bjorn.wesen@xxxxxxx.com] wrote:
> The code would be really cluttered by that.. as far as possible it's
> better to let gcc handle this, after all that's what a compiler is for. 
> 
> I think the packed attribute in combination with ntohl/htonl (or
> corresponding macros suggested in this thread) would suffice..
> 
> Someone could check that the ARM GCC really does do the Right Thing when
> accessing a packed struct with > byte size but I think it does and in that
> case we won't need the mess with manual byte accesses.
> 
> BTW are the bluetooth protocol headers really that messed up that they've
> designed them without alignment in mind (i.e they are suboptimally
> processed by most architectures?)
> 
> -Bjorn
> 
> On Fri, 22 Sep 2000, Erwin Authried wrote:
> > I think a clean solution that solves the alignment- as well as
> > the endianness problems is a rewrite that uses macros similar to the
> > samba implementation:
> > 
> > * instead of structures, make #defines of the byte offsets:
> > #define xy 27
> > #define ...
> > 
> > * use macros to set/read values:
> > SSVAL(buffer,xy,value) instead of buffer->xy=value
> > and ... = SVAL(buffer,xy)
> > 
> > There are a lot of changes necessary, but that's propably unavoidable for
> > a really portable solution.
> > 
> > Regards,
> > 
> > Erwin
> > 
> > 
> 
>