public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Владимир Андреев" <volodya@netfolder.ru>
To: David Brown <david@westcontrol.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Structure layout in big/little endian modes
Date: Sat, 26 Nov 2011 17:04:00 -0000	[thread overview]
Message-ID: <CAJXPUYK5sLyNT4COVGVJnJRGOnAX+iqe7nrame4qf+iSAWtJdQ@mail.gmail.com> (raw)
In-Reply-To: <4ECDF9E6.9050708@westcontrol.com>

I think, yes. How to post request for adding this feature?

2011/11/24 David Brown <david@westcontrol.com>:
> On 23/11/2011 19:33, Владимир Андреев wrote:
>>
>> Hello all!
>>
>> I have some lack of understanding how to write endianness independent
>> definition of structure, which contains bit fields.
>>
>> For example, field, containing endpoint address in endpoint descriptor
>> of USB device, can be defined as follow:
>>
>> struct EndpointAddress
>> {
>>     UnsignedByte EndpointNumber: 4;
>>     UnsignedByte: 3;
>>     UnsignedByte TransferDirection: 1;
>> };
>>
>> All USB descriptors have little endian byte order (and filling
>> starting from least significant bit). If I would run some code which
>> uses such definition on big endian CPU, I will get incorrect result.
>>
>> Can I tell GCC to use for layout big/little endian mode without manual
>> changing structure layout for target CPU?
>>
>
> Unfortunately, no.
>
> It would be /really/ nice if there were a gcc attribute that could specify
> that.  Ideally you'd have something like
> "__attribute__((bitorder(lsbfirst)))", with other options such as
> "msbfirst", and "native".  I don't know whether that would involve major
> effort, or whether it could be handled as a simple front-end manipulation
> (basically treating the definition as though you'd included all implicit
> padding bits, and then reversed the order).
>
> Note that you can't call this "little-endian bit ordering" and "big-endian
> bit ordering" - the bit ordering is independent of the endianness.
>
> One issue to consider, however, is bitfields that are greater than one byte
> - do they change endianness?  There are a number of options to consider.
>
> A related issue is endianness of data - and I think that would be even more
> useful as an attribute, but would involve many more changes.  I have seen
> such an idea on other compilers, so it certainly can be done.
>
>
> I couldn't see any enhancement requests for something like this in the
> bugzilla list, but I'm sure it is something that could be useful to many
> people (especially for embedded programming).  Perhaps it is worth adding?
>
>



-- 
С уважением, Владимир

  reply	other threads:[~2011-11-26  5:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-23 21:31 Владимир Андреев
2011-11-23 22:10 ` Ian Lance Taylor
2011-11-24  8:00 ` Paweł Sikora
2011-11-24 12:31 ` David Brown
2011-11-26 17:04   ` Владимир Андреев [this message]
2011-11-26 17:23     ` Ian Lance Taylor
2011-11-27  5:20       ` David Brown
2011-11-27 21:25         ` David Brown
2011-11-28 10:23         ` Ian Lance Taylor
2011-11-28 13:30           ` Владимир Андреев
     [not found] <CAJXPUY+H_iS7=iRdxiF+JS0iycJV7d12XK3+1k=NU69=D0se_A@mail.gmail.com>
2011-11-24  8:09 ` Ian Lance Taylor

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=CAJXPUYK5sLyNT4COVGVJnJRGOnAX+iqe7nrame4qf+iSAWtJdQ@mail.gmail.com \
    --to=volodya@netfolder.ru \
    --cc=david@westcontrol.com \
    --cc=gcc-help@gcc.gnu.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 read-only IMAP folder(s) and NNTP newsgroup(s).