Hi, It was indeed compiler options, but not sure exactly which one. Previously we were using WR GNU compiler mips-wrs-linux-gnu-gcc, and when we replaced it with mips-wrs-linux-gnu-mips32_el-gpp-gcc bit operations are working perfectly. The system has been booted from a cramfs RAMDISK image. Thanks for your help Hemanth -----Original Message----- From: Jonathan Day [mailto:imipak@xxxxxxxxx] Sent: Thursday, July 20, 2006 11:15 PM To: Hemanth V (WT01 - Embedded Systems); linux-mips@xxxxxxxxxxxxxx Subject: Re: Bit operations work differently on MIPS and IA32 Hi, Well, looking at it, the word is aligned in exactly the same way but the bitfields are applied in the opposite direction. (In the ix32 example, the 6 bits are counting from the low end of the word, but on the MIPS are counting from the high end.) The first question one must ask is whether you are using the same toolchain for both and what compiler directives you are giving in each case. (If you are using GCC on the MIPS, it would also be good to know what sort of code it was compiled to generate by default. If you ask GCC for the version information, it'll give the compiler flags used.) Even with this information, as another poster noted, bitfield operations are not guaranteed to be portable. The best I, or anyone else, can do is see if there's anything obviously inconsistant in the compiler flags. If you absolutely need to use the bitfields you've listed, you CAN do a workaround. Either you can use a #ifdef to determine the order the bitfields are listed in the union, OR you can take 6 bits off each end and recombine the end you want to keep with the offset. (Optimizing the code could break either of these methods, as there is no guarantee where the optimizer will decide to place the fields. That would presumably be system-dependent, as different bytes may be easier to access on different architectures, so would be subject to different optimizations.) --- hemanth.venkatesh@xxxxxxxxx wrote: > Hi All, > > > > I ran the below program on an IA32 and AU1100 > machine, both being little > endian machines and got different results. Does > anyone know what could > be the cause of this behaviour. This problem is > blocking us from booting > the cramfs rootfs. > > > > #include <stdio.h> > > typedef unsigned int u32; > > main() > > { > > struct tmp{ > > u32 namelen:6,offset:26; > > }tmp1; > > > > (*(int *)(&tmp1))=0x4c0; > > > > printf("%d %d\n",tmp1.namelen,tmp1.offset); > > > > } > > > > Results on IA32 : 0 19 > > > > Results on AU1100 (MIPS): 0 1216 > > > > Thanks > > hemanth > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
