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

Groups > comp.programming > #2486 > unrolled thread

little-endian

Back to article view | Back to comp.programming

Contents

  little-endian bob <bob@coolfone.comze.com> - 2012-11-15 13:45 -0800
    Re: little-endian JJ <jaejunks@glegooilma-swapit.com> - 2012-11-15 23:33 +0000
    Re: little-endian bob <bob@coolfone.comze.com> - 2012-11-16 10:38 -0800
      Re: little-endian "Pascal J. Bourguignon" <pjb@informatimago.com> - 2012-11-16 23:32 +0100
        Re: little-endian BGB <cr88192@hotmail.com> - 2012-11-16 21:17 -0600
          Re: little-endian "Pascal J. Bourguignon" <pjb@informatimago.com> - 2012-11-17 10:26 +0100
            Re: little-endian "BartC" <bc@freeuk.com> - 2012-11-17 11:38 +0000
              Re: little-endian "Pascal J. Bourguignon" <pjb@informatimago.com> - 2012-11-17 13:56 +0100
                Re: little-endian BGB <cr88192@hotmail.com> - 2012-11-17 11:58 -0600
              Re: little-endian Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-17 19:35 +0000
                Re: little-endian "BartC" <bc@freeuk.com> - 2012-11-17 19:50 +0000
            Re: little-endian BGB <cr88192@hotmail.com> - 2012-11-17 11:30 -0600
              Re: little-endian Ian Collins <ian-news@hotmail.com> - 2012-11-18 09:28 +1300
                Re: little-endian Robert Wessel <robertwessel2@yahoo.com> - 2012-11-17 14:48 -0600
                  Re: little-endian BGB <cr88192@hotmail.com> - 2012-11-17 16:22 -0600
                    Re: little-endian Ian Collins <ian-news@hotmail.com> - 2012-11-18 15:17 +1300
                      Re: little-endian "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-11-18 09:13 +0100
                        Re: little-endian Ian Collins <ian-news@hotmail.com> - 2012-11-18 21:33 +1300
                          Re: little-endian "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-11-18 10:15 +0100
                        Re: little-endian BGB <cr88192@hotmail.com> - 2012-11-18 03:03 -0600
                          Re: little-endian "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-11-18 10:29 +0100
                            Re: little-endian BGB <cr88192@hotmail.com> - 2012-11-18 12:50 -0600
    Re: little-endian Robin Vowels <robin.vowels@gmail.com> - 2012-11-22 04:49 -0800
      Re: little-endian Jongware <jongware@no-spam.plz> - 2012-11-23 15:22 +0100
        Re: little-endian pacman@kosh.dhis.org (Alan Curry) - 2012-11-25 19:39 +0000
          Re: little-endian Jongware <jongware@no-spam.plz> - 2012-11-26 12:01 +0100
            Re: little-endian "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-11-26 14:02 +0100
              Re: little-endian Jongware <jongware@no-spam.plz> - 2012-11-26 15:34 +0100
                Re: little-endian "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-11-26 17:03 +0100
                Re: little-endian Robert Wessel <robertwessel2@yahoo.com> - 2012-11-26 17:44 -0600
                  Re: little-endian Robin Vowels <robin.vowels@gmail.com> - 2012-11-28 23:43 -0800
                    Re: little-endian Robert Wessel <robertwessel2@yahoo.com> - 2012-11-29 22:46 -0600
            Re: little-endian BGB <cr88192@hotmail.com> - 2012-11-26 08:30 -0600
          Re: little-endian Robin Vowels <robin.vowels@gmail.com> - 2012-11-28 23:45 -0800

Page 2 of 2 — ← Prev page 1 [2]

#2506

On Sun, 18 Nov 2012 03:03:52 -0600, BGB wrote:

> or when dealing with file-formats.

Provided the file as a transport is well-defined, which is not necessarily
the case. It depends on the operating system, some have record-oriented
files some do translation (most notably LF/CR stuff) etc. When the file is
read using a stream interface (e.g. fgetc), there is a whole pile of I/O
layers beneath that with their encoding and recoding skeletons in the
cupboard.

> other times (depending on how the format is used), it may make sense to 
> use structs, but simply define all of the members as byte-arrays, and 
> then use functions to read/write the values from the structures (this 
> makes things like type-alignment largely a non-issue).

I dropped using that pattern long ago. It is too complicated to maintain
and to keep portable with little or no performance advantages.

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

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

#2507

On 11/18/2012 3:29 AM, Dmitry A. Kazakov wrote:
> On Sun, 18 Nov 2012 03:03:52 -0600, BGB wrote:
>
>> or when dealing with file-formats.
>
> Provided the file as a transport is well-defined, which is not necessarily
> the case. It depends on the operating system, some have record-oriented
> files some do translation (most notably LF/CR stuff) etc. When the file is
> read using a stream interface (e.g. fgetc), there is a whole pile of I/O
> layers beneath that with their encoding and recoding skeletons in the
> cupboard.
>

typically, I do most IO in binary mode.

the usual notion of a file is that it is a "bag of bytes".


>> other times (depending on how the format is used), it may make sense to
>> use structs, but simply define all of the members as byte-arrays, and
>> then use functions to read/write the values from the structures (this
>> makes things like type-alignment largely a non-issue).
>
> I dropped using that pattern long ago. It is too complicated to maintain
> and to keep portable with little or no performance advantages.
>

IMO, it works ok for times where a person wants to essentially 
memory-map a large structure without having to decode the whole thing in 
the process (it may be decoded incrementally).

this is in contrast to linearly reading/writing values, which is better 
for data which is encoded/decoded linearly, rather than incrementally or 
random-access.


usually, this means parts of things like "image-files" and similar, many 
of these formats also incorporating data compression (sometimes, it is 
data that may be only MB on disk, but when unpacked may take up around 
500MB-1GB or more of RAM).

so, one may end up with data which gets compressed and decompressed 
dynamically.

usually those byte-based structures may end up being things like 
index-tables or directory-tables, which refer to the actual data (which 
may be compressed).


or such...

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

#2510

On Nov 16, 8:45 am, bob <b...@coolfone.comze.com> wrote:
>                                    Am I the only one who constantly gets confused that little-endian stores the big stuff at the end?
>
> Seems like a misnomer.

Little endian is so-called because it's the least-significant byte
that
is fetched first.

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

#2512

On 22-Nov-12 13:49 PM, Robin Vowels wrote:
> On Nov 16, 8:45 am, bob <b...@coolfone.comze.com> wrote:
>>                                     Am I the only one who constantly gets confused that little-endian stores the big stuff at the end?
>>
>> Seems like a misnomer.
>
> Little endian is so-called because it's the least-significant byte
> that
> is fetched first.

The smallest value comes first? Then it should be called 'little beginning".

Intel desktop CPUs are little-endian; since a value 0x01234567 gets 
stored in four consecutive bytes as

data+0 : 0x67
data+1 : 0x45
data+2 : 0x23
data+3 : 0x01

the 'littlest' value gets placed at the end.

[Jw]

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

#2515

In article <50af8697$0$6979$e4fe514c@news2.news.xs4all.nl>,
Jongware  <jongware@no-spam.plz> wrote:
>
>The smallest value comes first? Then it should be called 'little beginning".
>
>Intel desktop CPUs are little-endian; since a value 0x01234567 gets 
>stored in four consecutive bytes as
>
>data+0 : 0x67
>data+1 : 0x45
>data+2 : 0x23
>data+3 : 0x01
>
>the 'littlest' value gets placed at the end.

You're insisting on the wrong meaning of the word "end", leading you to the 
conclusion that an object has one end, and the opposite of the end is the
beginning. Look at the source material:

(http://www.gutenberg.org/files/829/829.txt)
|It began upon the following occasion.  It is allowed on all hands,
|that the primitive way of breaking eggs, before we eat them, was
|upon the larger end; but his present majesty's grandfather, while
|he was a boy, going to eat an egg, and breaking it according to
|the ancient practice, happened to cut one of his fingers.
|Whereupon the emperor his father published an edict, commanding
|all his subjects, upon great penalties, to break the smaller end
|of their eggs.

All your statements using the phrases "the beginning" and "the end" are
meaningless because in the sense used in the story, an egg has 2 ends and no
beginnings. You can start eating it by breaking it on the big end or the
little end.

-- 
Alan Curry

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

#2518

On 25-Nov-12 20:39 PM, Alan Curry wrote:
> In article <50af8697$0$6979$e4fe514c@news2.news.xs4all.nl>,
> Jongware  <jongware@no-spam.plz> wrote:
>>
>> The smallest value comes first? Then it should be called 'little beginning".
>>
>> Intel desktop CPUs are little-endian; since a value 0x01234567 gets
>> stored in four consecutive bytes as
>>
>> data+0 : 0x67
>> data+1 : 0x45
>> data+2 : 0x23
>> data+3 : 0x01
>>
>> the 'littlest' value gets placed at the end.
>
> You're insisting on the wrong meaning of the word "end", leading you to the
> conclusion that an object has one end, and the opposite of the end is the
> beginning. Look at the source material:
>
> (http://www.gutenberg.org/files/829/829.txt)
> |It began upon the following occasion.  It is allowed on all hands,
> |that the primitive way of breaking eggs, before we eat them, was
> |upon the larger end; but his present majesty's grandfather, while
> |he was a boy, going to eat an egg, and breaking it according to
> |the ancient practice, happened to cut one of his fingers.
> |Whereupon the emperor his father published an edict, commanding
> |all his subjects, upon great penalties, to break the smaller end
> |of their eggs.
>
> All your statements using the phrases "the beginning" and "the end" are
> meaningless because in the sense used in the story, an egg has 2 ends and no
> beginnings. You can start eating it by breaking it on the big end or the
> little end.

This canonical example -- Gulliver's Travels -- was written to 
illustrate the absurdedness of human behavior. When used in a 
quantifiable, enumeratable environment such as "the order of bytes in 
memory" it makes perfect sense, since memory has an enumerated 
"beginning" (0) and "end" (the maximum address). It's not as if the 
nomenclature has been adopted by a random process.

[Jw]

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

#2519

On Mon, 26 Nov 2012 12:01:32 +0100, Jongware wrote:

> This canonical example -- Gulliver's Travels -- was written to 
> illustrate the absurdedness of human behavior. When used in a 
> quantifiable, enumeratable environment such as "the order of bytes in 
> memory" it makes perfect sense, since memory has an enumerated 
> "beginning" (0) and "end" (the maximum address).

1. Ends of an egg are clearly "enumeratable," since there are only two of
them. Lilliputians successfully enumerated them as "little end" and "big
end." The problem here is not human behavior nor inability to enumerate,
the problem is lack of preferred order. There are more than one way to
enumerate ends of an egg.

2. Regarding memory beginning and end, it is only a flat memory model which
has them. Otherwise see:

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

Machine addresses are not necessarily a total order, not even necessarily
comparable, especially when dealing with 8-/16-bit architectures.

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

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

#2521

On 26-Nov-12 14:02 PM, Dmitry A. Kazakov wrote:
> On Mon, 26 Nov 2012 12:01:32 +0100, Jongware wrote:
>
>> This canonical example -- Gulliver's Travels -- was written to
>> illustrate the absurdedness of human behavior. When used in a
>> quantifiable, enumeratable environment such as "the order of bytes in
>> memory" it makes perfect sense, since memory has an enumerated
>> "beginning" (0) and "end" (the maximum address).
>
> 1. Ends of an egg are clearly "enumeratable," since there are only two of
> them. Lilliputians successfully enumerated them as "little end" and "big
> end." The problem here is not human behavior nor inability to enumerate,
> the problem is lack of preferred order. There are more than one way to
> enumerate ends of an egg.
>
> 2. Regarding memory beginning and end, it is only a flat memory model which
> has them. Otherwise see:
>
> http://en.wikipedia.org/wiki/X86_memory_segmentation
>
> Machine addresses are not necessarily a total order, not even necessarily
> comparable, especially when dealing with 8-/16-bit architectures.

Hardware makes no difference. There are memory configurations with even 
bytes in one memory bank and odd bytes in another, but from the 
perspective of a CPU, any unit longer than a byte is still either 
big-endian or little-endian (*). "The perspective of a CPU" is "when 
reading consecutive bytes, how are those to be assembled into a longer 
unit". It doesn't really matter if these 'consecutive bytes' /actually/ 
come from different memory segments, memory banks, or in the form of 
zeros and ones off an infinitely long magnetic tape.

(*) Let's forget "middle-endian" systems for now, to not further add to 
the confusion :)

[Jw]

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

#2522

On Mon, 26 Nov 2012 15:34:48 +0100, Jongware wrote:

> On 26-Nov-12 14:02 PM, Dmitry A. Kazakov wrote:
>> On Mon, 26 Nov 2012 12:01:32 +0100, Jongware wrote:
>>
>>> This canonical example -- Gulliver's Travels -- was written to
>>> illustrate the absurdedness of human behavior. When used in a
>>> quantifiable, enumeratable environment such as "the order of bytes in
>>> memory" it makes perfect sense, since memory has an enumerated
>>> "beginning" (0) and "end" (the maximum address).
>>
>> 1. Ends of an egg are clearly "enumeratable," since there are only two of
>> them. Lilliputians successfully enumerated them as "little end" and "big
>> end." The problem here is not human behavior nor inability to enumerate,
>> the problem is lack of preferred order. There are more than one way to
>> enumerate ends of an egg.
>>
>> 2. Regarding memory beginning and end, it is only a flat memory model which
>> has them. Otherwise see:
>>
>> http://en.wikipedia.org/wiki/X86_memory_segmentation
>>
>> Machine addresses are not necessarily a total order, not even necessarily
>> comparable, especially when dealing with 8-/16-bit architectures.
> 
> Hardware makes no difference. There are memory configurations with even 
> bytes in one memory bank and odd bytes in another, but from the 
> perspective of a CPU, any unit longer than a byte is still either 
> big-endian or little-endian (*).

Least addressable machine unit is not necessarily byte. E.g. some DSP's had
it 32-bit, AFAIK.

> "The perspective of a CPU" is "when 
> reading consecutive bytes, how are those to be assembled into a longer 
> unit".

"Consecutive" presumes certain address arithmetic. Which brings you back to
the issue of the memory model. Let us not forget the addressing modes!

Of course, you could always enumerate all memory units just because any
computer is a finite state machine. But that does not mean that the way you
did it, is how the things are. Moreover the order may depend on the machine
state, e.g. numerically same addresses may correspond to physically
different units. It is just a model, it is not the reality. This is why
endianness issue exists.

> It doesn't really matter if these 'consecutive bytes' /actually/ 
> come from different memory segments, memory banks, or in the form of 
> zeros and ones off an infinitely long magnetic tape.

Yes, if you handle these units locally. In that case you may ignore details
provided that what you write is what you read back (not always so, but
almost always).

But if these memory units are used to communicate with the outer world,
both sides must use same order.

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

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

#2525

On Mon, 26 Nov 2012 15:34:48 +0100, Jongware <jongware@no-spam.plz>
wrote:

>On 26-Nov-12 14:02 PM, Dmitry A. Kazakov wrote:
>> On Mon, 26 Nov 2012 12:01:32 +0100, Jongware wrote:
>>
>>> This canonical example -- Gulliver's Travels -- was written to
>>> illustrate the absurdedness of human behavior. When used in a
>>> quantifiable, enumeratable environment such as "the order of bytes in
>>> memory" it makes perfect sense, since memory has an enumerated
>>> "beginning" (0) and "end" (the maximum address).
>>
>> 1. Ends of an egg are clearly "enumeratable," since there are only two of
>> them. Lilliputians successfully enumerated them as "little end" and "big
>> end." The problem here is not human behavior nor inability to enumerate,
>> the problem is lack of preferred order. There are more than one way to
>> enumerate ends of an egg.
>>
>> 2. Regarding memory beginning and end, it is only a flat memory model which
>> has them. Otherwise see:
>>
>> http://en.wikipedia.org/wiki/X86_memory_segmentation
>>
>> Machine addresses are not necessarily a total order, not even necessarily
>> comparable, especially when dealing with 8-/16-bit architectures.
>
>Hardware makes no difference. There are memory configurations with even 
>bytes in one memory bank and odd bytes in another, but from the 
>perspective of a CPU, any unit longer than a byte is still either 
>big-endian or little-endian (*). "The perspective of a CPU" is "when 
>reading consecutive bytes, how are those to be assembled into a longer 
>unit". It doesn't really matter if these 'consecutive bytes' /actually/ 
>come from different memory segments, memory banks, or in the form of 
>zeros and ones off an infinitely long magnetic tape.
>
>(*) Let's forget "middle-endian" systems for now, to not further add to 
>the confusion :)


Also needing to be excluded are machines with minimum addressable
units larger than a byte (IOW, word-addressed machines).  On word
addressed machines without hardware sub-word access, endianness is
just by (software) convention.

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

#2539

On Nov 27, 10:43 am, Robert Wessel <robertwess...@yahoo.com> wrote:

> Also needing to be excluded are machines with minimum addressable
> units larger than a byte (IOW, word-addressed machines).  On word
> addressed machines without hardware sub-word access, endianness is
> just by (software) convention.

Even with word machines (with or without hardware sub-word access)
there is an endian-ness for precision requiring multiple words,
and structures, etc.

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

#2547

On Wed, 28 Nov 2012 23:43:22 -0800 (PST), Robin Vowels
<robin.vowels@gmail.com> wrote:

>On Nov 27, 10:43 am, Robert Wessel <robertwess...@yahoo.com> wrote:
>
>> Also needing to be excluded are machines with minimum addressable
>> units larger than a byte (IOW, word-addressed machines).  On word
>> addressed machines without hardware sub-word access, endianness is
>> just by (software) convention.
>
>Even with word machines (with or without hardware sub-word access)
>there is an endian-ness for precision requiring multiple words,
>and structures, etc.


But that's usually only a software issue.

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

#2520

On 11/26/2012 5:01 AM, Jongware wrote:
> On 25-Nov-12 20:39 PM, Alan Curry wrote:
>> In article <50af8697$0$6979$e4fe514c@news2.news.xs4all.nl>,
>> Jongware  <jongware@no-spam.plz> wrote:
>>>
>>> The smallest value comes first? Then it should be called 'little
>>> beginning".
>>>
>>> Intel desktop CPUs are little-endian; since a value 0x01234567 gets
>>> stored in four consecutive bytes as
>>>
>>> data+0 : 0x67
>>> data+1 : 0x45
>>> data+2 : 0x23
>>> data+3 : 0x01
>>>
>>> the 'littlest' value gets placed at the end.
>>
>> You're insisting on the wrong meaning of the word "end", leading you
>> to the
>> conclusion that an object has one end, and the opposite of the end is the
>> beginning. Look at the source material:
>>
>> (http://www.gutenberg.org/files/829/829.txt)
>> |It began upon the following occasion.  It is allowed on all hands,
>> |that the primitive way of breaking eggs, before we eat them, was
>> |upon the larger end; but his present majesty's grandfather, while
>> |he was a boy, going to eat an egg, and breaking it according to
>> |the ancient practice, happened to cut one of his fingers.
>> |Whereupon the emperor his father published an edict, commanding
>> |all his subjects, upon great penalties, to break the smaller end
>> |of their eggs.
>>
>> All your statements using the phrases "the beginning" and "the end" are
>> meaningless because in the sense used in the story, an egg has 2 ends
>> and no
>> beginnings. You can start eating it by breaking it on the big end or the
>> little end.
>
> This canonical example -- Gulliver's Travels -- was written to
> illustrate the absurdedness of human behavior. When used in a
> quantifiable, enumeratable environment such as "the order of bytes in
> memory" it makes perfect sense, since memory has an enumerated
> "beginning" (0) and "end" (the maximum address). It's not as if the
> nomenclature has been adopted by a random process.
>

the issue here though is the use of the term "end".

typically, in reference to the use of "little-endian" vs "big-endian", 
it is the question "which end of the number comes first".

typically, "little-endian" then means "little-end comes first" (or, 
"least significant byte comes first"), and "big-endian" means "big-end 
comes first" ("most significant byte comes first").

where "first" here can be taken as "lowest address in memory".

example (little-endian):
address+0=LSB ("little end")
...
address+3=MSB ("big end")

example (big-endian):
address+0=MSB ("big end")
...
address+3=LSB ("little end")

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

#2540

On Nov 26, 6:39 am, pac...@kosh.dhis.org (Alan Curry) wrote:

> All your statements using the phrases "the beginning" and "the end" are
> meaningless because in the sense used in the story, an egg has 2 ends and no
> beginnings. You can start eating it by breaking it on the big end or the
> little end.

Or you can cut it in halves, or you can peel the eggshell (as in the
case of a hard-boiled egg).

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.programming

csiph-web