linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: linuxppc-dev@lists.linuxppc.org
Subject: Re: Help with cross-endian bitfields?
Date: Fri, 5 May 2000 16:49:04 -0400	[thread overview]
Message-ID: <20000505164904.A29233@drow.res.cmu.edu> (raw)
In-Reply-To: <852568D6.006ADE94.00@D51MTA03.pok.ibm.com>; from jlquinn@us.ibm.com on Fri, May 05, 2000 at 03:27:21PM -0400


On Fri, May 05, 2000 at 03:27:21PM -0400, jlquinn@us.ibm.com wrote:
>
> Hi, all.  I'm working on getting the Advansys driver working and what
> appears to be the final stumbling block is a difference in the layout of
> bitfields between little-endian and big-endian systems.  In particular,
> there are structs like the following:
>
> struct blah {
>   uchar a : 3;
>   uchar b : 3;
>   uchar c : 2;
> }
>
> On a little endian machine, this works like I expect.  (blah & 0x07) ==
> blah.a is true.  On linuxppc (and apparently MacOS as well), this is NOT
> true.  blah.a refers to the 3 most significant bits.  The linuxppc behavior
> seems counterintuitive to me because I expected each successive member in a
> struct to be the next physical piece of data I encounter.
>
> Can someone tell me what's going on here?  Am I going to have to have
> ifdef's on these structs, or resort to mask macros, or is there a
> reasonable solution here.

As Dan Malek said, there is no defined ordering.  The compiler is free
to do whatever it wishes.  You can't assume that.  (I think.)

Also, by your intuition, the obvious thing IS happening.  Remember that
we are big-endian - the first thing in memory is big-endian.  Thus, it
follows logically that a should be in the first three (most
significant) bits.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  parent reply	other threads:[~2000-05-05 20:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-05 19:27 Help with cross-endian bitfields? jlquinn
2000-05-05 20:05 ` Dan Malek
2000-05-05 20:45   ` Josh Huber
2000-05-05 20:49 ` Daniel Jacobowitz [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-05-05 20:47 jlquinn
     [not found] <200005060514.AAA05188@lists.linuxppc.org>
2000-05-08  7:03 ` james woodyatt
2000-05-08  9:50   ` Geert Uytterhoeven
2000-05-08 10:13 D.J. Barrow
2000-05-08 14:19 ` Geert Uytterhoeven
2000-05-08 14:38 jlquinn

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=20000505164904.A29233@drow.res.cmu.edu \
    --to=drow@false.org \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /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 NNTP newsgroup(s).