[uClinux-dev] Platform independant structs

Peter Ogilvy petero at cvs.com.au
Tue Feb 18 02:19:02 EST 2003


Hi All,

Thanks for the replies

Fréderic DUBOIS wrote:
> No there is not. The solution you've found is IIRC an ersatz of the
> presentation layer in the OSI model. BTW you should also take care of the
> big endian/ little endian issue.

The OSI point is a good one. I guess I have to find a hack that works for
me in this case. I'm trying to avoid as much copying of the data as I can as 
our application is real time control of a fruit sorting machine.

I initially thought I'd got the endian changes wrong so spent some time 
playing around with that before I bit the bullet and printed what I was 
getting on the host out in hex. It was then light dawned and I saw I had a 
different problem.

Erwin Authried wrote:
> I think RPC may help you. See man rpcgen.

I had a look and this seems geared towards remote calls rather
than just passing a struct, and has the added overhead of having to
have a RPC server running and wrapping the call in XML. I dont
think its what I'm looking for. I did learn what SOAP is though. It
has happened since I started to stray away from the M$ dark side :-)

Matthias Welwarsky wrote:
> You could try gcc's __attribute__(("packed")) extension to C. AFAIK, this
> will store struct members without an alignment. I'm not sure if it also
> means that the struct can start at an unaligned position.
>
> However, you will probably see performance degradation, because if your
> platform just cannot do unaligned accesses, you'll have to emulate them
> anyway - either the compiler will have to, or you will have to by hand, or
> the kernel will have to via alignment traps.

This looks like a good solution. I can pad my struct so all the important 
stuff is on boundaries OK for both my host and target, if I only use 32bit 
aligned positions it should be right untill it gets ported to a 64bit CPU, 
and I cant see our fruit sorting machines going 64 bit for a while :-)

Regards,





More information about the uClinux-dev mailing list