macro BITS_BIG_ENDIAN

macro BITS_BIG_ENDIAN

[Sivan Balaji]

Hi all,
I am porting GCC to a new architecture.

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.

i.e

struct str
{
	int a: 3 ;
} svar ;

Note: 'int' size is 32bits

big-endian:
31                               0
+---+-----------------------------+
| a |				  |
+---+-----------------------------+

little-endian:
31                               0
+-----------------------------+---+
|                             | a |
+-----------------------------+---+

If not, what is to be done to get the above behaviour.

When I tried defining BITS_BIG_ENDIAN with one and zero the behaviour is as big-endian above.

I would like to know the behaviour for BITS_BIG_ENDIAN with examples.

Thanks in advance.

Re: macro BITS_BIG_ENDIAN

[James E Wilson]

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.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: macro BITS_BIG_ENDIAN

[DJ Delorie]

> There is no way to control the order of bit-field allocation.

Yet.

> This is the "right" way to do things.

No, it's just the easy way.  Given that the SH vendor compiler does it
the "other" way, by definition GCC is doing it wrong.

> Apparently, Red Hat has patches that allow one to switch the order
> of bit-field allocation, but these patches have not been
> contributed.

I've tried.  My first attempt was rejected.  I proposed some target
hooks to let me make a second attempt, but got no approval (or reason
for rejection) for them.

Re: 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.

Re: macro BITS_BIG_ENDIAN

[James E Wilson]

On Thu, 2004-09-09 at 23:37, Sivan Balaji wrote:
> Is the following, the behavior of BITS_BIG_ENDIAN?

No.

As I said in my previous message, the only effect of BITS_BIG_ENDIAN is
on the ZERO_EXTRACT/SIGN_EXTRACT RTL.  There is no effect on structure
layout.  It is merely an internal implementation detail, which only
matters is the target has bit-field extract (extv) or insert (insv)
instruction patterns.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: macro BITS_BIG_ENDIAN (re send)

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