Re: Structure layout in big/little endian modes

Re: Structure layout in big/little endian modes

[Ian Lance Taylor]

Владимир Андреев <volodya@netfolder.ru> writes:

> Yes, it's the case. But I want more intuitive code without definitions of
> masks, shifts, etc. Thats why I chose bit fields.

Using bitfields is fine as long as you understand that they are not
portable between processors.  If you want portability, don't use
bitfields.

Ian

Re: Structure layout in big/little endian modes

[Владимир Андреев]

I think, it's better to discuss here syntax and its semantics and then
form common opinion.

I can sketch my vision of this enhancement.

2011/11/26 Ian Lance Taylor <iant@google.com>:
> David Brown <david.brown@hesbynett.no> writes:
>
>> Do you think it makes sense to file the enhancement request as I
>> described in my post, or is it better to discuss it more in the
>> mailing lists (either this one, or the gcc development list)?  It's a
>> feature I'd like to see implemented, but I don't want to clutter the
>> bugzilla with a request if you think it is highly unlikely to be
>> implemented -
>> then it just wastes time for everyone.
>
> As with all gcc enhancements, the best way to make it happen is to do it
> yourself.  I think that if somebody produced a clean patch for this
> functionality, it would be accepted.  But it's true that it wouldn't
> hurt to raise it on the mailing list to see if somebody is strongly
> opposed to it.
>
>
>> And for filing a request,
>> would you prefer me to give a suggestion for the syntax and the effect
>> it would have, or is it better to leave it open until someone
>> interested in implementing it forms an opinion?
>
> It helps to have a suggestion for the syntax.
>
> Ian
>



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

Re: Structure layout in big/little endian modes

[Ian Lance Taylor]

David Brown <david.brown@hesbynett.no> writes:

> Do you think it makes sense to file the enhancement request as I
> described in my post, or is it better to discuss it more in the
> mailing lists (either this one, or the gcc development list)?  It's a
> feature I'd like to see implemented, but I don't want to clutter the
> bugzilla with a request if you think it is highly unlikely to be
> implemented - 
> then it just wastes time for everyone.

As with all gcc enhancements, the best way to make it happen is to do it
yourself.  I think that if somebody produced a clean patch for this
functionality, it would be accepted.  But it's true that it wouldn't
hurt to raise it on the mailing list to see if somebody is strongly
opposed to it.


> And for filing a request,
> would you prefer me to give a suggestion for the syntax and the effect
> it would have, or is it better to leave it open until someone
> interested in implementing it forms an opinion?

It helps to have a suggestion for the syntax.

Ian

Re: Structure layout in big/little endian modes

[David Brown]

On 26/11/11 07:22, Ian Lance Taylor wrote:
> Владимир Андреев<volodya@netfolder.ru>  writes:
>
>> I think, yes. How to post request for adding this feature?
>
> File an enhancement request at http://gcc.gnu.org/bugzilla/ .
>
> Ian
>

Do you think it makes sense to file the enhancement request as I 
described in my post, or is it better to discuss it more in the mailing 
lists (either this one, or the gcc development list)?  It's a feature 
I'd like to see implemented, but I don't want to clutter the bugzilla 
with a request if you think it is highly unlikely to be implemented - 
then it just wastes time for everyone.  And for filing a request, would 
you prefer me to give a suggestion for the syntax and the effect it 
would have, or is it better to leave it open until someone interested in 
implementing it forms an opinion?

mvh.,

David

Re: Structure layout in big/little endian modes

[David Brown]

On 26/11/11 07:22, Ian Lance Taylor wrote:
> Владимир Андреев<volodya@netfolder.ru>  writes:
>
>> I think, yes. How to post request for adding this feature?
>
> File an enhancement request at http://gcc.gnu.org/bugzilla/ .
>
> Ian
>

Do you think it makes sense to file the enhancement request as I 
described in my post, or is it better to discuss it more in the mailing 
lists (either this one, or the gcc development list)?  It's a feature 
I'd like to see implemented, but I don't want to clutter the bugzilla 
with a request if you think it is highly unlikely to be implemented - 
then it just wastes time for everyone.  And for filing a request, would 
you prefer me to give a suggestion for the syntax and the effect it 
would have, or is it better to leave it open until someone interested in 
implementing it forms an opinion?

mvh.,

David

Re: Structure layout in big/little endian modes

[Ian Lance Taylor]

Владимир Андреев <volodya@netfolder.ru> writes:

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

File an enhancement request at http://gcc.gnu.org/bugzilla/ .

Ian

Re: Structure layout in big/little endian modes

[Владимир Андреев]

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?
>
>



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

Re: Structure layout in big/little endian modes

[David Brown]

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?

Re: Structure layout in big/little endian modes

[Paweł Sikora]

On Wednesday 23 of November 2011 19:33:01 Владимир Андреев 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.

some times ago i've established a nice c++ wrapper for byteorder conversion
and operation on bits/bytes ranges. please see for core source parts on
 http://pluto.agmk.net/src/portable_bit_masking.tgz

Re: Structure layout in big/little endian modes

[Ian Lance Taylor]

Владимир Андреев <volodya@netfolder.ru> writes:

> 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?

If you want to make your code work on different systems, even ones that
don't differ in endianness, don't use bitfields.  Use <<, >>, &, |.

Ian

Structure layout in big/little endian modes

[Владимир Андреев]

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?

-- 
With best regards, Vladimir