Bit operations work differently on MIPS and IA32

Bit operations work differently on MIPS and IA32

[hemanth.venkatesh]

[-- 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 --]

Bit operations work differently on MIPS and IA32

[hemanth.venkatesh]

[-- 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 --]

Re: Bit operations work differently on MIPS and IA32

[Thiemo Seufer]

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

Re: Bit operations work differently on MIPS and IA32

[Jonathan Day]

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 

RE: Bit operations work differently on MIPS and IA32

[hemanth.venkatesh]

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 

RE: Bit operations work differently on MIPS and IA32

[hemanth.venkatesh]

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