From: Sivan Balaji <SivanÃalaji@acmet.com>
To: James E Wilson <wilson@specifixinc.com>
Cc: gcc@gcc.gnu.org
Subject: Re: macro BITS_BIG_ENDIAN (re send)
Date: Fri, 10 Sep 2004 07:31:00 -0000 [thread overview]
Message-ID: <41414DC5.3010207@acmet.com> (raw)
In-Reply-To: <4140DBB9.8010901@specifixinc.com>
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.
prev parent reply other threads:[~2004-09-10 6:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-09 10:25 macro BITS_BIG_ENDIAN Sivan Balaji
2004-09-09 22:50 ` James E Wilson
2004-09-09 23:08 ` DJ Delorie
2004-09-10 6:53 ` Sivan Balaji
2004-09-10 19:39 ` James E Wilson
2004-09-10 7:31 ` Sivan Balaji [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41414DC5.3010207@acmet.com \
--to=sivanÃalaji@acmet.com \
--cc=gcc@gcc.gnu.org \
--cc=wilson@specifixinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).