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

Groups > comp.programming > #4783

Re: gcc-4.x.x and endianess

Show key headers only | View raw

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

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web