Hi, if you want such things you generally also need a big endian version, you need big endian packing (with swapping low and high byte) and a little endian packing; maybe also PDP and cross endianess and other things like a trap representation. But you can all do this with some macros or functions or do some conversion at the interfaces. I think the best thing would be an endianess and packing independent core and interfaces with endianess and packing conversions because packing is not portable in ANSI-C.
Regards, Rolf mspgcc-users@lists.sourceforge.net schrieb am 04.01.05 13:25:27: > > Hi, > > I agree; but, I felt that the feature would have proven useful because > my code is a protocol stack and packed structures are being used in the > packet headers and command frames (where, unfortunately, the size of the > comprising fields is not always in the increasing order of size). I wanted > to recompile the code using mspgcc and without much tinkering with the code. > > > Regards, > Sudhakar > > " This e-mail, and any attachments thereto, are intended only for use by the > addressee(s) named herein and contain Honeywell confidential information. If > you are not the intended recipient of this e-mail, you are hereby notified > that any dissemination, distribution or copying which amounts to > misappropriation of this e-mail and any attachments thereto, is strictly > prohibited. If you have received this e-mail in error, please immediately > notify me and permanently delete the original and any copy of any e-mail and > any printout thereof." > > > > -----Original Message----- > From: mspgcc-users-ad...@lists.sourceforge.net > [mailto:mspgcc-users-ad...@lists.sourceforge.net]on Behalf Of > nobo...@web.de > Sent: Tuesday, January 04, 2005 17:29 > To: mspgcc-users@lists.sourceforge.net > Subject: RE: [Mspgcc-users] Problem with packed structures.. > > > Hi, > > > In reply to Chris' post - The IAR compiler handles such structures by > > accessing the data byte by byte. So, assigning the value, 0x1234 to "hg.b" > > (odd memory location) is done one byte at a time, i.e. 0x34 is moved in > > first and then 0x12 is moved into the next higher byte. As Chris rightly > > pointed out, it would've been nice if mspgcc could generate similar code > :-) > > i don't agree because a) this produces more (assembler) code which needs > more flash, > b) it's slower and c) it's not necessary when you do define your struct as > > { > int i; > char c; > } > > instead of the ugly > > { > char c; > int i; > } > . > You should follow the generally rule that a struct should start with the > greatest member and that the > member n should be smaller or equal then member n-1. But you also have to > bear in mind > the alignment. > > Regards, > > Rolf > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
