How to change bit-field allocation

How to change bit-field allocation

[Min ZOU]

HI,

As I know, GCC allocates bit-fields inside a structure from the lowest
addressed byte, i.e. LSB, for little endian. However, I want to reverse
the ordering for the bit-fields allocation, i.e. always from MSB.

How to achieve this in GCC?

Thanks!

-- 
Best Regards

Min

Re: How to change bit-field allocation

[Ramana Radhakrishnan]

Hi Min, 

> HI,
> 
> As I know, GCC allocates bit-fields inside a structure from the lowest
> addressed byte, i.e. LSB, for little endian. However, I want to reverse
> the ordering for the bit-fields allocation, i.e. always from MSB.

The info pages seem to say and I quote 

<begin quote>

— Macro: BITS_BIG_ENDIAN

    Define this macro to have the value 1 if the most significant bit
in a byte has the lowest number; otherwise define it to have the value
zero. This means that bit-field instructions count from the most
significant bit. If the machine has no bit-field instructions, then
this must still be defined, but it doesn't matter which value it is
defined to. This macro need not be a constant.

    This macro does not affect the way structure fields are packed
into bytes or words; that is controlled by BYTES_BIG_ENDIAN.

— Macro: BYTES_BIG_ENDIAN

    Define this macro to have the value 1 if the most significant byte
in a word has the lowest number. This macro need not be a constant.

<end quote>

http://gcc.gnu.org/onlinedocs/gccint/Storage-Layout.html#Storage-Layout 



cheers
Ramana

-- 
Ramana Radhakrishnan

Re: How to change bit-field allocation

[James E Wilson]

Min ZOU wrote:
> As I know, GCC allocates bit-fields inside a structure from the lowest
> addressed byte, i.e. LSB, for little endian. However, I want to reverse
> the ordering for the bit-fields allocation, i.e. always from MSB.

You can't change the allocation order for bit-fields without changing 
the endianness of the processor.  A few moments thought should be enough 
to see the problem.  The normal rule is that a bitfield goes in the 
first avaiable bit.  You want it to go in the last available bit 
instead.  But the last bit of what?  If you want the last bit of the 
structure, then that is impossible to compute at this point because we 
don't know the size of the structure yet.  If you put it in the last bit 
of the current byte, then you run into problems if you have more than 8 
bits of bitfields.  If you put it in the last bit of the current word, 
then this probably works, but will add more padding then is absolutely 
necessary, and hence does not give exactly the same result as you would 
get for the other endianness.

What ever you are trying to do is probably wrong.  You probably should 
say what problem you are trying to solve, rather than asking how to 
implement particular solutions for it.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: How to change bit-field allocation

[Robert Dewar]

James E Wilson wrote:

> What ever you are trying to do is probably wrong.  You probably should 
> say what problem you are trying to solve, rather than asking how to 
> implement particular solutions for it.

I guess that the problem is that he wants a magical way of dealing with
endian differences between processors. Many people want this, but
unfortunately there is no coherent consistent way of doing this.
This topic has been much studied and discussed in the Ada world :-)

Re: How to change bit-field allocation

[Min ZOU]

Robert Dewar wrote:

> James E Wilson wrote:
> 
>> What ever you are trying to do is probably wrong.  You probably should 
>> say what problem you are trying to solve, rather than asking how to 
>> implement particular solutions for it.
> 
> 
> I guess that the problem is that he wants a magical way of dealing with
> endian differences between processors. Many people want this, but
> unfortunately there is no coherent consistent way of doing this.
> This topic has been much studied and discussed in the Ada world :-)
> 

The problem is not due to endian differences but compiler differences. I 
came across this problem when I have to combine two binary images while 
are compiled by different compilers: one by GCC, the other by SH 
proprietary compiler. However the bit-field's members are allocated from 
  the lower bit in GCC, while from higher bit in SH compiler.

RE: How to change bit-field allocation

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of James E Wilson
> Sent: 06 September 2004 22:44

> Min ZOU wrote:
> > As I know, GCC allocates bit-fields inside a structure from 
> the lowest
> > addressed byte, i.e. LSB, for little endian. However, I 
> want to reverse
> > the ordering for the bit-fields allocation, i.e. always from MSB.

>   The normal rule is that a bitfield goes in the 
> first avaiable bit.  You want it to go in the last available bit 
> instead.  But the last bit of what?  

  Um, what's wrong with saying "The underlying integer type" as an answer to
this question?  You needn't insist on the compiler reversing the order of
allocation of consecutive underlying-int-type-sized units when it build the
struct, just that it fills the current one in the reverse direction.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: How to change bit-field allocation

[tm_gccmail]

On Mon, 6 Sep 2004, James E Wilson wrote:

> Min ZOU wrote:
> > As I know, GCC allocates bit-fields inside a structure from the lowest
> > addressed byte, i.e. LSB, for little endian. However, I want to reverse
> > the ordering for the bit-fields allocation, i.e. always from MSB.
> 
> You can't change the allocation order for bit-fields without changing 
> the endianness of the processor.  A few moments thought should be enough 
> to see the problem.  The normal rule is that a bitfield goes in the 
> first avaiable bit.  You want it to go in the last available bit 
> instead.  But the last bit of what?  If you want the last bit of the 
> structure, then that is impossible to compute at this point because we 
> don't know the size of the structure yet.  If you put it in the last bit 
> of the current byte, then you run into problems if you have more than 8 
> bits of bitfields.  If you put it in the last bit of the current word, 
> then this probably works, but will add more padding then is absolutely 
> necessary, and hence does not give exactly the same result as you would 
> get for the other endianness.
> 
> What ever you are trying to do is probably wrong.  You probably should 
> say what problem you are trying to solve, rather than asking how to 
> implement particular solutions for it.

The SH is bi-endian.

I don't know what he's doing, but in the context of this, it may make
sense.

Toshi

Re: How to change bit-field allocation

[DJ Delorie]

> As I know, GCC allocates bit-fields inside a structure from the
> lowest addressed byte, i.e. LSB, for little endian. However, I want
> to reverse the ordering for the bit-fields allocation, i.e. always
> from MSB.

I submitted a patch to do this a while back as part of my Renesas
patches.  It was rejected as it exceeded the hack threshold for the
code it was modifying.  I recently submitted a proposal to move the
bitfield layout code into a set of target hooks, so that different
methods could be implemented more cleanly, but it has yet to be
approved.

The first passes at the patch (We've since fixed some bugs in this
internally, since we still use it for some internal branches):
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02503.html
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00815.html
(or search for "reverse_bitfield_layout")

Request to make it into target hooks:
http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00132.html

Proposal to move to target hooks:
http://gcc.gnu.org/ml/gcc/2004-06/msg01193.html

Re: How to change bit-field allocation

[Min ZOU]

Thanks a lot for your help!

BTW, I found in the latest Renesas SH proprietary compiler, there is 
already an option to change the default bit-field allocation so that 
bit-field's members are allocated from the lower bit, which is same as GCC.

DJ Delorie wrote:

>>As I know, GCC allocates bit-fields inside a structure from the
>>lowest addressed byte, i.e. LSB, for little endian. However, I want
>>to reverse the ordering for the bit-fields allocation, i.e. always
>>from MSB.
> 
> 
> I submitted a patch to do this a while back as part of my Renesas
> patches.  It was rejected as it exceeded the hack threshold for the
> code it was modifying.  I recently submitted a proposal to move the
> bitfield layout code into a set of target hooks, so that different
> methods could be implemented more cleanly, but it has yet to be
> approved.
> 
> The first passes at the patch (We've since fixed some bugs in this
> internally, since we still use it for some internal branches):
> http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02503.html
> http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00815.html
> (or search for "reverse_bitfield_layout")
> 
> Request to make it into target hooks:
> http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00132.html
> 
> Proposal to move to target hooks:
> http://gcc.gnu.org/ml/gcc/2004-06/msg01193.html

Re: How to change bit-field allocation

[Robert Dewar]

Min ZOU wrote:
> Thanks a lot for your help!
> 
> BTW, I found in the latest Renesas SH proprietary compiler, there is 
> already an option to change the default bit-field allocation so that 
> bit-field's members are allocated from the lower bit, which is same as GCC.

It seems fundamental to me that bit fields must be allocated in a
manner consistent with the processor addressing, or you can get
non-contiguous fields.

Re: How to change bit-field allocation

[Etienne Lorrain]

Min ZOU wrote:
> Robert Dewar wrote:
> > I guess that the problem is that he wants a magical way of dealing with
> > endian differences between processors. Many people want this, but
> > unfortunately there is no coherent consistent way of doing this.
> > This topic has been much studied and discussed in the Ada world :-)
>
> The problem is not due to endian differences but compiler differences. I >
came across this problem when I have to combine two binary images while
> are compiled by different compilers: one by GCC, the other by SH
> proprietary compiler. However the bit-field's members are allocated from
> the lower bit in GCC, while from higher bit in SH compiler.

  I had the impression that only one logical way was possible depending
 on the processor, so that:

union {
  unsigned char val1;
  unsigned      val2 : 8;
  unsigned char val3[1];
  struct { unsigned char c1, c2; } val3;
  ... whatever ...
  } a_union;

 the value of "a_union.val1", "a_union.val2",  "a_union.val3[0]" and
 "a_union.val3.c1" are identical - assuming 8 bits chars.

  Same for (assuming 16 bits shorts):
union {
  unsigned short val1;
  unsigned       val2 : 16;
  enum { e1, e2, e3 } val3 : 16;
  } union2;

  Etienne.


	

	
		
Vous manquez dÂ’espace pour stocker vos mails ? 
Yahoo! Mail vous offre GRATUITEMENT 100 Mo !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com