Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #4757 > unrolled thread

gcc-4.x.x and endianess

Back to article view | Back to comp.programming

Contents

  gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-13 21:41 -0400
    Re: gcc-4.x.x and endianess "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-14 09:14 +0200
      Re: gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-14 15:31 -0400
        Re: gcc-4.x.x and endianess "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-14 21:38 +0200
          Re: gcc-4.x.x and endianess Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-09-14 22:05 +0100
            Re: gcc-4.x.x and endianess "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-15 09:40 +0200
              Re: gcc-4.x.x and endianess Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-09-15 11:51 +0100
                Re: gcc-4.x.x and endianess "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-09-15 13:49 +0100
                Re: gcc-4.x.x and endianess "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-15 17:16 +0200
                  Re: gcc-4.x.x and endianess Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-09-15 22:23 +0100
                    Re: gcc-4.x.x and endianess "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-16 10:44 +0200
                  Re: gcc-4.x.x and endianess Kaz Kylheku <kaz@kylheku.com> - 2014-09-16 00:18 +0000
            Re: gcc-4.x.x and endianess BGB <cr88192@hotmail.com> - 2014-09-15 06:18 -0500
          Re: gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-15 14:23 -0400
            Re: gcc-4.x.x and endianess "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-15 21:08 +0200
              Re: gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-15 19:32 -0400
            Re: gcc-4.x.x and endianess Richard Heathfield <invalid@see.sig.invalid> - 2014-09-15 21:07 +0100
              Re: gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-15 21:48 -0400
    Re: gcc-4.x.x and endianess Jongware <jongware@no-spam.plz> - 2014-09-15 10:57 +0200
    Re: gcc-4.x.x and endianess "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-09-15 14:06 +0100
      Re: gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-15 21:50 -0400
        Re: gcc-4.x.x and endianess "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-09-17 09:54 +0100
          Re: gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-17 22:29 -0400

Page 1 of 2  [1] 2  Next page →

#4757 — gcc-4.x.x and endianess

    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

[toc] | [next] | [standalone]

#4758

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-kazakov.de

[toc] | [prev] | [next] | [standalone]

#4760

"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

[toc] | [prev] | [next] | [standalone]

#4761

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-kazakov.de

[toc] | [prev] | [next] | [standalone]

#4764

"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.

[toc] | [prev] | [next] | [standalone]

#4767

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/%27Bit_Order

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

[toc] | [prev] | [next] | [standalone]

#4771

"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/%27Bit_Order

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.

[toc] | [prev] | [next] | [standalone]

#4773

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 

[toc] | [prev] | [next] | [standalone]

#4775

On Mon, 15 Sep 2014 11:51:29 +0100, in comp.programming you wrote:

> "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.

Machine-independency is a method to handle endianness, in the sense of 
writing a program in a way that it would work on any machine with whatever 
endianness.

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

That is the position #2. Most programs should never resolve to #2.

>> [ 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.

Shifting signed integers.

> It is also a common
> misconception that casts expose endianness.

Of course they do, especially casts like *(T*) &x or ((A*) &x) [i]

> Obviously C *can* reveal
> the representation of its types (though pointers and unions for
> example) but casts are defined as value conversions in C.

The point exactly is that it "can". In a properly designed language it 
should be "cannot", unless explicitly demanded by the programmer involving 
some heavy syntax clearly distinguishable from daily used constructs.

>> 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/%27Bit_Order
> 
> 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)."

It controls bit-endinness.

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

In the article everywhere the keyword "at" appears. E.g.

type WORD is record
   High : BYTE;
   Low : BYTE;
end record;
for WORD use record
   High at 0 range 0..7;
   Low at 1 range 0..7;
end record;

Here Higher_Order is at the byte (memory unit) 0. To make it little-endian

for WORD use record
   High at 1 range 0..7;
   Low at 0 range 0..7;
end record;

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

[toc] | [prev] | [next] | [standalone]

#4783

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

> On Mon, 15 Sep 2014 11:51:29 +0100, in comp.programming you wrote:
>
>> "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.
>
> Machine-independency is a method to handle endianness, in the sense of 
> writing a program in a way that it would work on any machine with whatever 
> endianness.

I thought you were saying something specific about endianess rather than
the usual machine-dependence of C's type ranges.

>>> 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?
>
> That is the position #2. Most programs should never resolve to #2.

Sorry, I don't follow what this means.

>>> [ 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.
>
> Shifting signed integers.

It's a common misconception that shifts in C have something to do with
endianness.

>> It is also a common
>> misconception that casts expose endianness.
>
> Of course they do, especially casts like *(T*) &x or ((A*) &x) [i]

Not "especially".  The endianness is exposed by the pointer, and no
casts are need to do that -- it's getting a pointer that, of course,
exposes the 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.
>
> The point exactly is that it "can". In a properly designed language it 
> should be "cannot", unless explicitly demanded by the programmer involving 
> some heavy syntax clearly distinguishable from daily used constructs.

Sure.  That's a defensible position, but not what you seemed to be
saying.

>>> 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/%27Bit_Order
>> 
>> 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)."
>
> It controls bit-endinness.

Yes, but I did not think that is what was being discussed.  The usual
meaning of the term endian relates to the mapping between successive
byte addresses and numerical significance.  (Bit addressed machine
having, to intents and purposes, died out.)

>> Could you give an example of an endianness problem that is solved using
>> this attribute?
>
> In the article everywhere the keyword "at" appears. E.g.
>
> type WORD is record
>    High : BYTE;
>    Low : BYTE;
> end record;
> for WORD use record
>    High at 0 range 0..7;
>    Low at 1 range 0..7;
> end record;
>
> Here Higher_Order is at the byte (memory unit) 0. To make it little-endian
>
> for WORD use record
>    High at 1 range 0..7;
>    Low at 0 range 0..7;
> end record;

I think we may disagree on what endianness is.  Many languages (C
included) allow you alter the order in which structure or record fields
occur.  It's neat that Ada can separate the layout of a record type
from the type declaration, but that's not the issue is it?  Can one
alter the layout of a numerical type in Ada, so that, for example you
could read an IP port number from a stream and get the right numerical
value?  That would be a very nice touch.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#4788

On Mon, 15 Sep 2014 22:23:37 +0100, Ben Bacarisse wrote:

> I think we may disagree on what endianness is.

http://en.wikipedia.org/wiki/Endianness

> Many languages (C
> included) allow you alter the order in which structure or record fields
> occur.  It's neat that Ada can separate the layout of a record type
> from the type declaration, but that's not the issue is it?  Can one
> alter the layout of a numerical type in Ada,

In which sense alter? Do you expect the resulting numeric type operations
being implemented by the hardware? Sorry, no language can rewire the CPU.

If you mean a mere user-defined numeric type of the said layout with
operations defined by the user. You can do that for the record type:

   type WORD is private;
   function "+" (Left, Right : WORD) return WORD;
   ...
private
   type WORD is record  ...

This would be possible to do in any more or less advanced language. So
managing the record layout is all what is needed.

> so that, for example you
> could read an IP port number from a stream and get the right numerical
> value?

It is a very bad idea. You never need all this stuff when dealing with I/O
protocols. The only place where layout representation has any use is
systems programming, mapping machine registers. Yes, I/O ports are such
registers, but anything above that is to be implemented per
serialization/deserialization of the corresponding types.

Note that serialization/deserialization can be written in a portable way
and layout representation cannot.

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

[toc] | [prev] | [next] | [standalone]

#4785

On 2014-09-15, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Mon, 15 Sep 2014 11:51:29 +0100, in comp.programming you wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> [ 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.
>
> Shifting signed integers.

Shifting integers in C has nothing to do with endianness.
Firstly, it has some well-defined portable behaviors, which are
all arithmetically defined. For instance if we shift a signed int
value like 42 to the left by a position (42 << 1), this is
defined by the ISO standard as producing 84, because well-defined (not out of
range) shifts are multiplications or divisions by a power of two.
It produces 82 regardless of how many bytes make up that int,
or how it is stored in memory into those bytes.

Shifts expose certain inherent nonportabilities of the integral types,
but these are not tied to endiannness. They are tied to the representation,
and range. Representation and range are abstract properties defined
in terms of a field of bits, independently how those bits are stored
in memory.

>> It is also a common
>> misconception that casts expose endianness.
>
> Of course they do, especially casts like *(T*) &x or ((A*) &x) [i]

Type punning does provide the tool for revealing endiannness. If we are on a
platform where the type int consists of two or more bytes and does not contain
padding bits (the majority of them), we can take an object of type int in which
the value 1 is stored, and see which byte has a nonzero bit.  If it is the
lowest-addressed byte, for instance, then it's probably a little-endian
platform.

>
>> Obviously C *can* reveal
>> the representation of its types (though pointers and unions for
>> example) but casts are defined as value conversions in C.
>
> The point exactly is that it "can". In a properly designed language it 

Please stop using words like "properly", when referring to you personal
preferences.

> should be "cannot", unless explicitly demanded by the programmer involving 
> some heavy syntax clearly distinguishable from daily used constructs.

Heavy syntax is naive; because if a smart programmer is confronted with
cumbersome syntax, he or she can easily add a component to the toolchain
to generate that syntax from a simpler syntax: a macro preprocessor, or
a full blown compiler for a light-weight notation into the cumbersome
language.

You might think that the heavy syntax at least impede the B grade programmers,
but that is not true: the tool can be well documented and made widely
available.

(Usually the result, though, is that the cumbersome language is simply eschewed.
Programmers, by and large, are a pragmatic lot: when "hello world" takes 100
lines in some language, they instinctively avoid it.)

In C, you will not expose endianness unless you use specific syntax, like casts
or unions. The syntax isn't "heavy", but it's not invisible.  It's light enough
that programmers don't automatically run for the macro preprocessor to hide it.

[toc] | [prev] | [next] | [standalone]

#4772

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).

[toc] | [prev] | [next] | [standalone]

#4778

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

[snip]

But I guess people like C mostly for its
> deficiencies.

    Deficiencies? I call that low level ability.

Bill

[toc] | [prev] | [next] | [standalone]

#4781

On Mon, 15 Sep 2014 14:23:51 -0400, Bill Cunningham wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1szke6pe4wjgd$.wpsri6v7srjm.dlg@40tude.net...
> 
> [snip]
> 
> But I guess people like C mostly for its
>> deficiencies.
> 
>     Deficiencies? I call that low level ability.

Low level ability deficiencies, yes. C is pretty poor at the low level, if
by that you mean closeness to the hardware. It was designed for PDP
machines which were much different from modern CPUs, e.g. they had
everything addressable, even registers were. Basically C fails at every
level.

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

[toc] | [prev] | [next] | [standalone]

#4784

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

> Low level ability deficiencies, yes. C is pretty poor at the low level, if
> by that you mean closeness to the hardware. It was designed for PDP
> machines which were much different from modern CPUs, e.g. they had
> everything addressable, even registers were. Basically C fails at every
> level.

    PDPs I believe were middle endianess. I don't know of any machines now 
that are that type of achitecture. But the bitwise ops, that's pretty unique 
IMO.

Bill

[toc] | [prev] | [next] | [standalone]

#4782

Bill Cunningham wrote:

> 
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1szke6pe4wjgd$.wpsri6v7srjm.dlg@40tude.net...
> 
> [snip]
> 
> But I guess people like C mostly for its
>> deficiencies.
> 
>     Deficiencies? I call that low level ability.

Bill, I never thought I'd say this to you, but... please don't feed the 
troll.

It is clear that Mr Kazakov is attempting to goad C programmers into 
defending the C language, which is rather like trying to goad oceanographers 
into defending the ocean.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#4786

"Richard Heathfield" <invalid@see.sig.invalid> wrote in message 
news:wGHRv.384520$m41.14317@fx34.am4...

> Bill, I never thought I'd say this to you, but... please don't feed the
> troll.
>
> It is clear that Mr Kazakov is attempting to goad C programmers into
> defending the C language, which is rather like trying to goad 
> oceanographers
> into defending the ocean.

Perhaps you're right this has nothing to do with the OP. And nothing about 
modern compiler's capabilities.

Bill

[toc] | [prev] | [next] | [standalone]

#4769

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]

[toc] | [prev] | [next] | [standalone]

#4774

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-Order.html
(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 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.programming

csiph-web