* Bit operations work differently on MIPS and IA32
@ 2006-07-20 16:02 ` hemanth.venkatesh
0 siblings, 0 replies; 6+ messages in thread
From: hemanth.venkatesh @ 2006-07-20 16:02 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 576 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 4554 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Bit operations work differently on MIPS and IA32 @ 2006-07-20 16:02 ` hemanth.venkatesh 0 siblings, 0 replies; 6+ messages in thread From: hemanth.venkatesh @ 2006-07-20 16:02 UTC (permalink / raw) To: linux-mips [-- Attachment #1: Type: text/plain, Size: 576 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 4554 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bit operations work differently on MIPS and IA32 2006-07-20 16:02 ` hemanth.venkatesh (?) @ 2006-07-20 16:18 ` Thiemo Seufer -1 siblings, 0 replies; 6+ messages in thread From: Thiemo Seufer @ 2006-07-20 16:18 UTC (permalink / raw) To: hemanth.venkatesh; +Cc: linux-mips hemanth.venkatesh@wipro.com 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; This makes non-portable assumptions about the bitfield layout. The results are platform-dependent (or rather ABI-dependent). Portable code needs to avoid acessing bitfields via typecasts. Thiemo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bit operations work differently on MIPS and IA32 2006-07-20 16:02 ` hemanth.venkatesh (?) (?) @ 2006-07-20 17:45 ` Jonathan Day 2006-07-21 6:51 ` hemanth.venkatesh -1 siblings, 1 reply; 6+ messages in thread From: Jonathan Day @ 2006-07-20 17:45 UTC (permalink / raw) To: hemanth.venkatesh, linux-mips 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@wipro.com 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Bit operations work differently on MIPS and IA32 @ 2006-07-21 6:51 ` hemanth.venkatesh 0 siblings, 0 replies; 6+ messages in thread From: hemanth.venkatesh @ 2006-07-21 6:51 UTC (permalink / raw) To: imipak; +Cc: linux-mips 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@yahoo.com] Sent: Thursday, July 20, 2006 11:15 PM To: Hemanth V (WT01 - Embedded Systems); linux-mips@linux-mips.org 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@wipro.com 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Bit operations work differently on MIPS and IA32 @ 2006-07-21 6:51 ` hemanth.venkatesh 0 siblings, 0 replies; 6+ messages in thread From: hemanth.venkatesh @ 2006-07-21 6:51 UTC (permalink / raw) To: imipak; +Cc: linux-mips 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@yahoo.com] Sent: Thursday, July 20, 2006 11:15 PM To: Hemanth V (WT01 - Embedded Systems); linux-mips@linux-mips.org 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@wipro.com 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-07-21 6:52 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-07-20 16:02 Bit operations work differently on MIPS and IA32 hemanth.venkatesh 2006-07-20 16:02 ` hemanth.venkatesh 2006-07-20 16:18 ` Thiemo Seufer 2006-07-20 17:45 ` Jonathan Day 2006-07-21 6:51 ` hemanth.venkatesh 2006-07-21 6:51 ` hemanth.venkatesh
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.