[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming

gcc-4.x.x and endianess

Bill Cunningham

9/14/2014 1:42:00 AM

I was wondering if anyone familiar with the gcc-4 series of GNU
compilers know if these compilers have any type of built in capability to
deal with endianess and MSB and LSB on various machines, and processors.

Bill
22 Answers

Dmitry A. Kazakov

9/14/2014 7:15:00 AM

0

On Sat, 13 Sep 2014 21:41:53 -0400, Bill Cunningham wrote:

> I was wondering if anyone familiar with the gcc-4 series of GNU
> compilers know if these compilers have any type of built in capability to
> deal with endianess and MSB and LSB on various machines, and processors.

I am not sure what do you mean by compiler capacity to deal with
endianness. But languages compiled by the compiler have it, e.g. Ada. GNAT
Ada compiler is a GCC front-end (available for GCC 4.6, 4,7, 4.8, 4.9).
Does that qualify GCC?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-...

Bill Cunningham

9/14/2014 7:32:00 PM

0


"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:m9su0868osqi.od5en2j049hq$.dlg@40tude.net...

> I am not sure what do you mean by compiler capacity to deal with
> endianness. But languages compiled by the compiler have it, e.g. Ada. GNAT
> Ada compiler is a GCC front-end (available for GCC 4.6, 4,7, 4.8, 4.9).
> Does that qualify GCC?

I know there are various front end to gcc. I just write in C. With some
machines you have to re-write code because of the machine's endianess. That
might only be with assembley and old assemblers I don't know.

Bill

Dmitry A. Kazakov

9/14/2014 7:38:00 PM

0

On Sun, 14 Sep 2014 15:31:31 -0400, Bill Cunningham wrote:

> I just write in C. With some
> machines you have to re-write code because of the machine's endianess. That
> might only be with assembley and old assemblers I don't know.

That depends on how the code is written. With C chances are high, because
it does not offer any means to handle endianness nor to declare types in a
machine-independent way. But I guess people like C mostly for its
deficiencies.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-...

Ben Bacarisse

9/14/2014 9:06:00 PM

0

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 14 Sep 2014 15:31:31 -0400, Bill Cunningham wrote:
>
>> I just write in C. With some
>> machines you have to re-write code because of the machine's endianess. That
>> might only be with assembley and old assemblers I don't know.
>
> That depends on how the code is written. With C chances are high, because
> it does not offer any means to handle endianness nor to declare types in a
> machine-independent way. But I guess people like C mostly for its
> deficiencies.

What means do other languages offer to handle endianness?

--
Ben.

Dmitry A. Kazakov

9/15/2014 7:40:00 AM

0

On Sun, 14 Sep 2014 22:05:57 +0100, Ben Bacarisse wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> On Sun, 14 Sep 2014 15:31:31 -0400, Bill Cunningham wrote:
>>
>>> I just write in C. With some
>>> machines you have to re-write code because of the machine's endianess. That
>>> might only be with assembley and old assemblers I don't know.
>>
>> That depends on how the code is written. With C chances are high, because
>> it does not offer any means to handle endianness nor to declare types in a
>> machine-independent way. But I guess people like C mostly for its
>> deficiencies.
>
> What means do other languages offer to handle endianness?

1. Types declared in problem space terms, when it is machine-independent
and, thus, endianness-agnostic. Like:

type Salary is range 0..1_000_000; -- I don't care about endianness

[ which also presumes that the language does not provide means to expose
endianness through legal operations defined on the type. E.g. whatever you
write with the type the result would not depend on the endianness. In C you
have shifts and type casts which expose endinness. In a safe language such
things if exist then guarded against unintentional use. ]

2. Control over the type representation aspects (endianness is one of them)
when it must really be machine-dependent. E.g. see here

http://en.wikibooks.org/wiki/Ada_Programming/Attributes/%2...

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-...

Jongware

9/15/2014 8:58:00 AM

0

On 14-Sep-14 3:41 AM, Bill Cunningham wrote:
> I was wondering if anyone familiar with the gcc-4 series of GNU
> compilers know if these compilers have any type of built in capability to
> deal with endianess and MSB and LSB on various machines, and processors.

They do not; primarily because the *compiler* cannot guess what the
*programmer* wants (other than literally interpreting the C code).

See this snippet of C:

int get_some_value (int aLongInteger)
{
return *((char *)aLongInteger);
}

This will return `aLongInteger & 0xff` on an LSB machine, `(aLongInteger
>> (sizeof int - sizeof char)) & 0xff` on an MSB machine (if I get my
endiannessnesses right). What is the compiler to do? It does not "know"
which one is meant.

Flat-out refusing to compile it would be safest -- then again, this is
an easily spotted case.

To be portable (at least for this aspect), code should be written *not*
to assume *anything* about endianness. Which IMO is not any harder than
*deliberately* (ab-)using it.

[Jw]

Ben Bacarisse

9/15/2014 10:51:00 AM

0

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 14 Sep 2014 22:05:57 +0100, Ben Bacarisse wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> On Sun, 14 Sep 2014 15:31:31 -0400, Bill Cunningham wrote:
>>>
>>>> I just write in C. With some
>>>> machines you have to re-write code because of the machine's endianess. That
>>>> might only be with assembley and old assemblers I don't know.
>>>
>>> That depends on how the code is written. With C chances are high, because
>>> it does not offer any means to handle endianness nor to declare types in a
>>> machine-independent way. But I guess people like C mostly for its
>>> deficiencies.
>>
>> What means do other languages offer to handle endianness?
>
> 1. Types declared in problem space terms, when it is machine-independent
> and, thus, endianness-agnostic.

You seemed to draw a distinction between machine-independent types and
handling endianness. The former I understand, it was the latter I was
unclear about.

> Like:
>
> type Salary is range 0..1_000_000; -- I don't care about endianness

Are there any languages where the basic types *do* care about
endianness? What would that look like from the point of view of the
program?

> [ which also presumes that the language does not provide means to expose
> endianness through legal operations defined on the type. E.g. whatever you
> write with the type the result would not depend on the endianness. In C you
> have shifts and type casts which expose endinness.

That's a common misconception about shifts in C. It is also a common
misconception that casts expose endianness. Obviously C *can* reveal
the representation of its types (though pointers and unions for
example) but casts are defined as value conversions in C.

> In a safe language such
> things if exist then guarded against unintentional use. ]
>
> 2. Control over the type representation aspects (endianness is one of them)
> when it must really be machine-dependent. E.g. see here
>
> http://en.wikibooks.org/wiki/Ada_Programming/Attributes/%2...

I'm not sure which part of that page you are referring to because t does
not seem to be directly related to handling endianness. In the end it
says:

"The 'Bit_Order attribute is not intended to convert data between a
big-endian and a little-endian machine (it affects bit numbering, not
byte order)."

Could you give an example of an endianness problem that is solved using
this attribute?

--
Ben.

cr88192

9/15/2014 11:19:00 AM

0

On 9/14/2014 4:05 PM, Ben Bacarisse wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> On Sun, 14 Sep 2014 15:31:31 -0400, Bill Cunningham wrote:
>>
>>> I just write in C. With some
>>> machines you have to re-write code because of the machine's endianess. That
>>> might only be with assembley and old assemblers I don't know.
>>
>> That depends on how the code is written. With C chances are high, because
>> it does not offer any means to handle endianness nor to declare types in a
>> machine-independent way. But I guess people like C mostly for its
>> deficiencies.
>
> What means do other languages offer to handle endianness?
>

in my scripting language, it is possible to use modifiers which declare
explicit endianess, which effect storage of the datatypes in some cases,
but the VM can ignore it if it will have no effect (typically in
function arguments and local variables).

I have wanted similar in C a few times.
my custom C frontend adds a few modifiers, but isn't really usable at
present.

otherwise, in C one needs to use wrapper functions, which work but are
often less convenient. a wrapper can though be made to work with
different compilers.

a "safer" way to glue it onto C proper would probably be via compiler
intrinsics.


how does one do it in functions?
load/save in terms of bytes and shifts, which is simple/portable but not
particularly efficient;
rely on machine-specific load/store behavior in cases where it is
applicable (such as x86 and newer ARM having unaligned little-endian
loads/stores);
use inline ASM, where one can utilize specific CPU instructions to
handle the endianess efficiently (for example, on x86 one can use
"BSWAP", ...).

though, granted, being able to be like:
i=*(__bigendian __unaligned __int32 *)cs;
would be convinient, even if:
i=bgbbtj_gets32be(cs);
is both more portable and more compact in this case.


more often the modifiers would be used in struct declarations (where the
struct can be declared in a way which makes it, theoretically,
machine-independent).

Chris Uppal

9/15/2014 12:50:00 PM

0

Ben Bacarisse wrote:

> Are there any languages where the basic types *do* care about
> endianness? What would that look like from the point of view of the
> program?

I've never heard of one, and it'd have to be pretty odd, since the underlying
machine instruction set doesn't care about it either.

I don't know of any circumstances where endianness is even /visible/ except
where treating the same physical storage as if it had multiple types (e.g.
treating an integer as a string of bytes, or a double as an integer (not
casting, but getting at the underlying binary representation)). The biggest
example of such aliassing is, of course, IO.

-- chris


Chris Uppal

9/15/2014 1:07:00 PM

0

Bill Cunningham wrote:
> I was wondering if anyone familiar with the gcc-4 series of GNU
> compilers know if these compilers have any type of built in capability to
> deal with endianess and MSB and LSB on various machines, and processors.

What are you looking for over and above what:
http://www.gnu.org/software/libc/manual/html_node/Byte-...
(htons() and friends) gives you ? htons() probably goes all the way back to
day 1.

The compiler also has builtin near equivalents like:
__builtin_bswap32()
which presumably are faster, but I don't know when they were added.

-- chris