On Mon, Jan 12, 2009 at 11:31 PM, Urs Hunkeler <[email protected]> wrote: > By "pad/no-pad option" you mean the "__attribute__ ((packed))" compiler > attribute? Philip Levis in "TinyOS Programming" (e.g. > http://csl.stanford.edu/~pal/pubs/tinyos-programming.pdf) explains how > this works and why it should not be used. According to the above referenced > document, all fields in an nx_struct are aligned on byte boundaries. So I > guess this means the structure is "packed". > > I would expect the implementation of the nx_ types to be platform > dependent. If you look at the code for the MicaX platforms, there likely is > not much to see. However, the implementation for the Telos type of platforms > might be quite a bit more complex. Maybe this does not show in the packet > definition, but when accessing those variables, the code must do something > to change the endianness and to access 2-byte values that are not aligned on > 2-byte boundaries.
My take on the nx_types is that they were introduced to deal with what does a packet looks like on the wire. It deals with both the packing problem as well as endianess. The end result of nx_types must be by definition be platform independent, thats the whole point. The implementation must also be by definition be platform dependent because the intent is nx_types marry a given platform to network order so data packets can make sense across different machines and the right thing still happens. I've looked at the C code generated from use of nx_ types and the data is stored in arrays of bytes. Nested byte arrays. And when data is inserted or extratacted appropriate byte swap routines (some machines do nothing, others actually have to byte swap and reorder) are used for multibyte objects. The chief determinant of what gets generated is what endianess is the machine and what is network order (big endian). eric > > Cheers, > Urs > > Michael Schippling wrote: > >> I think the pad/no-pad thing is probably a compiler level feature >> and was most certainly for multi-byte objects on differing platforms. >> (The OP's struct had an int16-int8-int16, which on some platforms >> would have been layed out as int16-int8-padbyte-int16...or worse). >> Given that nx_ types are byte arrays they don't need it and are >> probably packed efficiently. Being an old guy I never trust that >> new-fangled stuff and thus avoid it...but thanks for the info. >> >> MS >> >> Eric Decker wrote: >> >>> >>> On Mon, Jan 12, 2009 at 11:17 AM, Michael Schippling >>> <[email protected]<mailto: >>> [email protected]>> wrote: >>> >>> There "used to be" a pad/no-pad option especially for this. >>> Are the nx_ types defined to always be no-pad? >>> >>> >>> I've looked at the code generated and the nx_types are defined as arrays >>> of uint8_t. Not sure >>> how the pad no_pad used to work. I suspect it is for multibyte objects >>> such as uint16_t etc. >>> >>> But for the question originally asked int8_t were being asked about. >>> >>> eric >>> >> -- Eric B. Decker Senior (over 50 :-) Researcher Autonomous Systems Lab Jack Baskin School of Engineering UCSC
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
