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?
>
>
--
С уважением, Владимир
next prev parent 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).