macro BITS_BIG_ENDIAN

[Sivan Balaji]

I tried to get the behavior from the following example.

struct str_tag
{
	int a:3 ;
} str_var = {1} ;

Note: 'int' size is 32bits

1. BYTES_BIG_ENDIAN defined to 0

1.1 BITS_BIG_ENDIAN defined to 0
Assembly output for bits little-endian:
	.size	str_var, 4
str_var:
	.byte	1
	.space	3

1.2 BITS_BIG_ENDIAN defined to 1
Assembly output for bits big-endian:
	.size	str_var, 4
str_var:
	.byte	1
	.space	3

2. BYTES_BIG_ENDIAN defined to 1

2.1 BITS_BIG_ENDIAN defined to 0
Assembly output for bits little-endian:
	.size	str_var, 4
str_var:
	.byte	32
	.space	3

2.2 BITS_BIG_ENDIAN defined to 1
Assembly output for bits big-endian:
	.size	str_var, 4
str_var:
	.byte	32
	.space	3

Is the following, the behavior of BITS_BIG_ENDIAN?

bytes little-endian and bits little-endian:
 7       0 7       0 7       0 7       0 
+---------+---------+---------+-----+---+
|         |         |         |     |001|
+---------+---------+---------+-----+---+
31      24 23     16 15      8 7       0 

bytes little-endian and bits big-endian:
 0       7 0       7 0       7 0       7 
+---------+---------+---------+-----+---+
|         |         |         |     |001|
+---------+---------+---------+-----+---+
24      31 16     23 8      15 0       7 

Thanks in advance,
Balaji Sivan

_James E Wilson wrote, on 9/10/2004 4:09 AM_:
> Sivan Balaji wrote:
> 
>> I have been through GCC internals documentation and I am not clear 
>> about BITS_BIG_ENDIAN. does BITS_BIG_ENDIAN related to the order of 
>> bit field members allocation.
> 
> 
> There is no way to control the order of bit-field allocation. Bit-fields 
> are always assigned to the first available bit, possibly constrained by 
> other factors, such as alignment.  That means that they start at the low 
> order bit for little-endian, and the high order bit for big-endian.  
> This is the "right" way to do things.  It is very unusual for a compiler 
> to do this differently.
> 
> The only thing controlled by BITS_BIG_ENDIAN is the bit numbering used 
> for bit-field instructions.  Or more specifically, it controls how the 
> operands to ZERO_EXTRACT and SIGN_EXTRACT RTL operators are interpreted. 
>  It has no other effect.
> 
> Apparently, Red Hat has patches that allow one to switch the order of 
> bit-field allocation, but these patches have not been contributed.