![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 5 | Archive 6 | Archive 7 | Archive 8 | Archive 9 |
I removed the mentioning of endianness sometimes referring to bit order. This is not true. The name of the variable BYTES_BIG_ENDIAN
seems to suggest that endianness is related to bit order. Note, however, that BYTES_BIG_ENDIAN
is the name of a variable and not a definition of the term Endianness. Furthermore the meaning of the variable BYTES_BIG_ENDIAN
has been defined as the order of bits in a bit field. Endianness refers to the order of digits. Even if we define a digit as a set of one bit, endianness still refers to the ordering of the digits and not of the bits. The bit order is defined by its weight (MSB, LSB).
[1]
95.172.177.37 ( talk) 07:26, 14 October 2019 (UTC)
BYTES_BIG_ENDIAN
is NOT "defined as the order of bits in a bit field". That's the order of bit fields within a structure, not the order of bits within a bit field, and it's BITS_BIG_ENDIAN
, not BYTES_BIG_ENDIAN
- the order of bytes within multi-byte values and the order of bit fields within a structure are not necessarily the same.BYTES_BIG_ENDIAN
is a #define the value of which, on a particular platform, indicates the byte-endianness of that platform, and BITS_BIG_ENDIAN
is a #define the value of which, on a particular platform, indicates the bit-endianness of the code generated for that platform. The byte-endianness might be dictated by the instruction set architecture of the platform (for example, x86 doesn't easily support big-endian storage of data, and System/3x0 and z/Architecture don't easily support little-endian storage of data), or it might be an option (for example, PowerPC/Power ISA can run in little-endian or big-endian mode - I think a given Power ISA machine might be able to have one virtual machine/LPAR running AIX or IBM i in big-endian mode, another one running Linux in big-endian mode, and yet another one running Linux in little-endian mode). The bit-endianness might be be less dependent on the hardware - if the machine has bit-field instructions, it might make the bit endianness match that, but if it doesn't, it's largely up to the compiler.+---+-------+------+ | C | B | A | +---+-------+------+
+---+-------+------+ | A | B | C | +---+-------+------+
References
Removal of This is confusing to mix position ordering and memory ordering at the same time in an example seems right to me, but I thought it could be discussed. Among others is the connection between left to right order, and low to high addressing. Memory in computers doesn't have a left or right! It is convenient to number print columns increasing to the right, but note the VMS DUMP command, which prints hex data right to left, for easier reading. Gah4 ( talk) 02:09, 15 May 2020 (UTC)
This is analogous to the lowest address of memory being used first.from the 2nd paragraph in the section Endianess#Illustration, which is introducing big and little endianness with the analogy of left and right.
«logically most-significant byte of a word of digital data» is too weak as a specification. I indeed assume that endianness pertains to numerical data in place-value notation. E.g. "UNIX" is also digital data, and the "U" could be considered the most-significant byte. - Nomen4Omen ( talk) 19:54, 29 May 2020 (UTC)
@
Kbrose:
Somehow I am completely helpless how it is possible that you misunderstand me so severely. Is it my poor English?
Didn't I say:
How is it possible that you conclude
But I remain asking you how you can say in the most important section, namely
Endianness#Definition:
“The right-side graphic shows the little-endian definition. With increasing memory address, the logical significance of each byte increases, so that the most-significant byte is stored at the highest address of the storage region.” And not restricting this definition to numerical —as it has been even in the lead of the article up to your edits— data being handled by the instructions of the different hardware architectures. The point is NOT to “propose a more universally fitting term”, but a definition which pertains to endianness. -
Nomen4Omen (
talk)
17:55, 31 May 2020 (UTC)
endianness is the ordering or sequencing of bytes of a word of digital data in computer memory storage or during transmission.I'm not sure that qualifying things with logical in the disputed text is helpful but I don't think it's wrong and I suggest Nomen4Omen needs to suggest an alternative if we're to contemplate changing it. ~ Kvng ( talk) 14:42, 3 June 2020 (UTC)
Danny Cohen talks about character and numerical data (integer and floating point). And storage address and transmission. And of the consistency of ordering the bits within these coordinate systems. It is kind of a philosophical view and tries to touch almost all aspects of ordering.
Earlier, other computer people had found out that the addresses are a major coordinate axis which can be used as orientation to talk about the other issues. (As to Danny Cohen, it looks as if the left-to-right axis is more important for him as this anchoring major axis. He also brings the direction of writing, whether left-to-right or top-down, into the discussion and investigates the consistency of all these coordinates.) Moreover, they found out that within character data one wants the first chunk (lowest address) to be the most discriminant one. (I do not really know about RTL writing, but I am not able to find a contradiction to this assumption — nowhere.) So character data are settled and do not require further consideration.
The remaining important type of data are the numerical data, and of them the most important ones the integer data; and handling such data was in the beginning the most important task of the computing machines. As far as I know the computing machines started with the decimal number system coded in Binary Coded Decimal (BCD) digits with the most significant decimal digit first. This is the second major coordinate axis: significance. Later some clever computer scientists found out that three of the four basic arithmetic operations naturally run from low-order to high-order, namely addition, subtraction and multiplication. The less important division and comparison runs the other way around. After implementing in hardware the correlation of the two major coordinates (increasing numerical significance = increasing address) there was a need to distinguish this approach from the previous one. At that time this was done using the manufacturer name. And it appears that there have been some holy wars, but after Danny Cohen's publication of ON HOLY WARS AND A PLEA FOR PEACE the term big-endian was used for anticorrelation (increasing address = decreasing significance) and little-endian for correlation.
So I propose to focus the article mainly on this kind of essence of endianness, i.e. on numerical data related to the coordinate axis of increasing addresses, which is a hardware issue. I propose, however, to include (at least in theory) bit endianness, because (as already Danny Cohen mentions) the bit-shift instructions induce (both, with left and right shift) a consistent ordering of the bytes to the bits. Of course, an outlook on Danny Cohen's more philosophical considerations is not to be suppressed. (But everybody is free to read it, it is easily accessible in the internet and it is really funny.) - Nomen4Omen ( talk) 16:58, 3 June 2020 (UTC)
The 80386 (eventually IA32) segment descriptor is an upward extension of the 80286 descriptor, such that 80286 code still runs. Also, OS such as OS/2 2.0 and up run OS/2 1.x (16 bit protected mode) code. The 80286 has a 24 bit segment origin, so the high bits ended up somewhere else. The 80286 has 16 bit segment length in units of bytes. As there weren't enough bits, the 80386 extends the length to 20 bits, but also has a bit indicating the the unit is 4K bytes. That allows lengths up to 4GB. Gah4 ( talk) 06:29, 9 July 2020 (UTC)
In the opening section there's a sentence containing, "it is an attribute of a computing machine resp. its hardware architecture"
What does this even mean? Can someone who understand the original intent please clarify and fix the text. I'd gladly do the edit, but can't parse what it's trying to say. mikro2nd ( talk) 09:25, 10 July 2020 (UTC)
@ Kbrose:
- Nomen4Omen ( talk) 18:24, 25 July 2020 (UTC)
@ Kbrose:
Questions over questions ! Are there other people who don't get your point ? - Nomen4Omen ( talk) 19:40, 25 July 2020 (UTC)
The current article section Endianness#Definition has problems. (I think this is what the previous talk discussion about the lede has wandered off into, but I haven't been able to usefully follow it.)
A possible cause of the problems (and confusion with the lede) may come from the section heading itself: "Definition". The definition of any article subject belongs in the lede; why does this article have it a separate following section? One good reason may be that the lede definition, though technically complete and accurate, isn't good for any layperson reader -- too full of jargon, implied context, etc. A good way to explain something like that is to give an analogy -- describing situations not precisely accurate or perfectly complete, but providing enough context to allow enough basic understanding to follow the rest of the subject information. It seems to me that's what this whole section is trying to do, with debatable success.
Before we focus on solutions to this section, can we agree on the goal? Should we change the name of this section to "Example" to do this? ("Analogy" might also accomplish this, but I think it's less engaging to a reader.)
Comments? -- A D Monroe III( talk) 19:00, 27 July 2020 (UTC)
Indeed, there is no example like "Hello world". But, IMHO, binary integer is classical enough. So I propose: ==The prominent example: binary integers== – Nomen4Omen ( talk) 07:03, 1 August 2020 (UTC)
The article states that "Danny Cohen introduced the terms big-endian and little-endian into computer science for data ordering, in an article published by the Internet Engineering Task Force (IETF) in 1980".
The IETF was only founded in 1986, it could not be the original source of publication. — Preceding unsigned comment added by HeidenChristenseun ( talk • contribs) 16:31, 20 September 2020 (UTC)
@
Vincent Lefèvre: OK, if you don't see (“don't see any relation with big-endian”) that the right shift of the byte sequence
(0x02, 0x01) >> 8
is a right shift (of the integer 513 resulting in 2) on a big-endian machine;
and the right shift of the very same byte sequence
(0x02, 0x01) >> 8
is a right shift (interestingly now of the integer 258, resulting in 1) on a little-endian machine, then I have to give up.
And I'm absolutely sure that I am not the first observer of this fact. But nevertheless, I am not at all interested in looking up the literature for former observers. –
Nomen4Omen (
talk)
13:08, 18 January 2021 (UTC)
Unix
(as already mentioned in the
article), and you shift it to the right on a big-endian then you get ␣Uni
(looking like a right shift), whereas on a little-endian you get nix␣
which is apparently a left-shift. –
Nomen4Omen (
talk)
15:03, 18 January 2021 (UTC)
@
Vincent Lefèvre:
It IS already mentioned in the
article. As a problem – i.e. a trap into which programmers already have fallen. And it tells us that only extremely few programmers have to write programs which have to deal with the problem – and extremely soon, namely during testing, will notice that there is a problem. But this problem is not presented in a systematic way in the article.
[By the way, do you know how RTL script is recorded in storage? On a big-endian machine? It is not easy to find that out. But there are good reasons for the assumption that the Hebrew bible is kept in storage starting with the thora at the low addresses. And because a right shift on a big-endian shifts into the high addresses this remains a right shift – and only on screen it appears as a left shift.] –
Nomen4Omen (
talk)
21:51, 18 January 2021 (UTC)
I'm tired of fighting this edit battle, but endianness is not just "bytes in a word" but rather describes arbitrary sets of bits within a bit vector. "Bytes within a word" is the most common use but this arbitrarily narrow definition does a disservice to our users. J.Mayer ( talk) 20:38, 13 November 2020 (UTC)
@
Cousteau: As far as I can find out in
Right-to-left mark#Example of use in HTML the first character of a Hebrew text appears on the right of the screen, but is recorded "first" (i.e. at the low address) in RAM. (See also the discussion one section higher with Vincent Lefèvre.) So the Hebrew bible would be held in storage starting with the thora at the low addresses. This would mean (as you say) "addresses increasing to the (screen-)left". But because the first char is the most significant one and is at the low RAM-address, this resembles the big-endian convention.
This would mean that right-to-left (RTL) languages do not have an intrinsic conflict in the (RAM-)big-endian systems!? And consequently have an intrinsic conflict in the little-endian systems!?
Or, in your words: "This conflict between the memory arrangements of binary data and text is intrinsic to the nature of the little-endian convention", and ―as we now know― is a conflict for languages written left-to-right, such as English, but also for RTL scripts!? ―
Nomen4Omen (
talk)
06:13, 28 April 2021 (UTC)
@
Cousteau:
@
Vincent Lefèvre:
Thank you both for your contributions.
I guess that much of the confusion is coming in by mixing up some reading or writing direction with the sequence of addresses in RAM or memory. As far as I can see, there are about 3 coordinates which are relevant in this discussion:
As far as I could find out, the reading, writing or "visualizing" (as
Vincent Lefèvre names it) direction has absolutely nothing at all to do with RAM addresses: texts stored in RAM have the character which is to be read first situated at the lowest RAM address (where it is impossible to visualize them) ― with the consequence that the coordinates relevant to endianness are totally unchanged by LTR or RTL scripting. (The direction in which things are displayed on screen is specified by extra
Right-to-left marks, located also in the computer memory.)
Whatever
Cousteau wanted to express with his insertion of "(On the other hand, right-to-left languages have a complementary intrinsic conflict in the big-endian system.)" it is wrong, because RTL scripts fit very well to and do not have a conflict with big-endian systems. (This kind of conflict arises only if one identifies the reading, writing or visualizing direction (on paper or on screen) with some recording direction in the RAM, an identification which seems to be very popular, but, in fact, is completely mislead.) −
Nomen4Omen (
talk)
08:02, 29 April 2021 (UTC)
od -x
program prints 16 bit words, such that the bytes of a word are in the wrong order. The VMS (hex) DUMP program prints the address in a column, with the ASCII values on the right, and read left to right, and the hex data on the left, read right to left. Some years ago, I went to a talk about RISC-V, where they handed out a (green) reference card. The instruction formats are written with the opcode on the right. It just looks weird to read instructions with the opcode on the right. (They are at lower address.) It is slightly easier to build a simple processor little-endian, such as the 6502. (Look at the 6502 CALL instruction for some fun), as addition, and so carry, is done LSB to MSB. But multiply and divide or done MSB to LSB, so it doesn't help on those machines. The 8080 is little-endian, as that is the way CTC designed the 8008. I suppose reading hex dumps is less common now, but it is still inconvenient for little-endian systems.
Gah4 (
talk)
08:27, 29 April 2021 (UTC)
References
Let's expose the points pertaining to the article:
So, as a concluding sentence of the paragraph Endianness#Byte addressing I find the previous
having more reality and relevance than your
But the truth is that plain text has nothing at all to do with endianness in its proper sense. And the interpretion of a hexdump cannot be the purpose of the article, everybody recommends to take a debugging course on that. ― Nomen4Omen ( talk) 14:07, 29 April 2021 (UTC)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 5 | Archive 6 | Archive 7 | Archive 8 | Archive 9 |
I removed the mentioning of endianness sometimes referring to bit order. This is not true. The name of the variable BYTES_BIG_ENDIAN
seems to suggest that endianness is related to bit order. Note, however, that BYTES_BIG_ENDIAN
is the name of a variable and not a definition of the term Endianness. Furthermore the meaning of the variable BYTES_BIG_ENDIAN
has been defined as the order of bits in a bit field. Endianness refers to the order of digits. Even if we define a digit as a set of one bit, endianness still refers to the ordering of the digits and not of the bits. The bit order is defined by its weight (MSB, LSB).
[1]
95.172.177.37 ( talk) 07:26, 14 October 2019 (UTC)
BYTES_BIG_ENDIAN
is NOT "defined as the order of bits in a bit field". That's the order of bit fields within a structure, not the order of bits within a bit field, and it's BITS_BIG_ENDIAN
, not BYTES_BIG_ENDIAN
- the order of bytes within multi-byte values and the order of bit fields within a structure are not necessarily the same.BYTES_BIG_ENDIAN
is a #define the value of which, on a particular platform, indicates the byte-endianness of that platform, and BITS_BIG_ENDIAN
is a #define the value of which, on a particular platform, indicates the bit-endianness of the code generated for that platform. The byte-endianness might be dictated by the instruction set architecture of the platform (for example, x86 doesn't easily support big-endian storage of data, and System/3x0 and z/Architecture don't easily support little-endian storage of data), or it might be an option (for example, PowerPC/Power ISA can run in little-endian or big-endian mode - I think a given Power ISA machine might be able to have one virtual machine/LPAR running AIX or IBM i in big-endian mode, another one running Linux in big-endian mode, and yet another one running Linux in little-endian mode). The bit-endianness might be be less dependent on the hardware - if the machine has bit-field instructions, it might make the bit endianness match that, but if it doesn't, it's largely up to the compiler.+---+-------+------+ | C | B | A | +---+-------+------+
+---+-------+------+ | A | B | C | +---+-------+------+
References
Removal of This is confusing to mix position ordering and memory ordering at the same time in an example seems right to me, but I thought it could be discussed. Among others is the connection between left to right order, and low to high addressing. Memory in computers doesn't have a left or right! It is convenient to number print columns increasing to the right, but note the VMS DUMP command, which prints hex data right to left, for easier reading. Gah4 ( talk) 02:09, 15 May 2020 (UTC)
This is analogous to the lowest address of memory being used first.from the 2nd paragraph in the section Endianess#Illustration, which is introducing big and little endianness with the analogy of left and right.
«logically most-significant byte of a word of digital data» is too weak as a specification. I indeed assume that endianness pertains to numerical data in place-value notation. E.g. "UNIX" is also digital data, and the "U" could be considered the most-significant byte. - Nomen4Omen ( talk) 19:54, 29 May 2020 (UTC)
@
Kbrose:
Somehow I am completely helpless how it is possible that you misunderstand me so severely. Is it my poor English?
Didn't I say:
How is it possible that you conclude
But I remain asking you how you can say in the most important section, namely
Endianness#Definition:
“The right-side graphic shows the little-endian definition. With increasing memory address, the logical significance of each byte increases, so that the most-significant byte is stored at the highest address of the storage region.” And not restricting this definition to numerical —as it has been even in the lead of the article up to your edits— data being handled by the instructions of the different hardware architectures. The point is NOT to “propose a more universally fitting term”, but a definition which pertains to endianness. -
Nomen4Omen (
talk)
17:55, 31 May 2020 (UTC)
endianness is the ordering or sequencing of bytes of a word of digital data in computer memory storage or during transmission.I'm not sure that qualifying things with logical in the disputed text is helpful but I don't think it's wrong and I suggest Nomen4Omen needs to suggest an alternative if we're to contemplate changing it. ~ Kvng ( talk) 14:42, 3 June 2020 (UTC)
Danny Cohen talks about character and numerical data (integer and floating point). And storage address and transmission. And of the consistency of ordering the bits within these coordinate systems. It is kind of a philosophical view and tries to touch almost all aspects of ordering.
Earlier, other computer people had found out that the addresses are a major coordinate axis which can be used as orientation to talk about the other issues. (As to Danny Cohen, it looks as if the left-to-right axis is more important for him as this anchoring major axis. He also brings the direction of writing, whether left-to-right or top-down, into the discussion and investigates the consistency of all these coordinates.) Moreover, they found out that within character data one wants the first chunk (lowest address) to be the most discriminant one. (I do not really know about RTL writing, but I am not able to find a contradiction to this assumption — nowhere.) So character data are settled and do not require further consideration.
The remaining important type of data are the numerical data, and of them the most important ones the integer data; and handling such data was in the beginning the most important task of the computing machines. As far as I know the computing machines started with the decimal number system coded in Binary Coded Decimal (BCD) digits with the most significant decimal digit first. This is the second major coordinate axis: significance. Later some clever computer scientists found out that three of the four basic arithmetic operations naturally run from low-order to high-order, namely addition, subtraction and multiplication. The less important division and comparison runs the other way around. After implementing in hardware the correlation of the two major coordinates (increasing numerical significance = increasing address) there was a need to distinguish this approach from the previous one. At that time this was done using the manufacturer name. And it appears that there have been some holy wars, but after Danny Cohen's publication of ON HOLY WARS AND A PLEA FOR PEACE the term big-endian was used for anticorrelation (increasing address = decreasing significance) and little-endian for correlation.
So I propose to focus the article mainly on this kind of essence of endianness, i.e. on numerical data related to the coordinate axis of increasing addresses, which is a hardware issue. I propose, however, to include (at least in theory) bit endianness, because (as already Danny Cohen mentions) the bit-shift instructions induce (both, with left and right shift) a consistent ordering of the bytes to the bits. Of course, an outlook on Danny Cohen's more philosophical considerations is not to be suppressed. (But everybody is free to read it, it is easily accessible in the internet and it is really funny.) - Nomen4Omen ( talk) 16:58, 3 June 2020 (UTC)
The 80386 (eventually IA32) segment descriptor is an upward extension of the 80286 descriptor, such that 80286 code still runs. Also, OS such as OS/2 2.0 and up run OS/2 1.x (16 bit protected mode) code. The 80286 has a 24 bit segment origin, so the high bits ended up somewhere else. The 80286 has 16 bit segment length in units of bytes. As there weren't enough bits, the 80386 extends the length to 20 bits, but also has a bit indicating the the unit is 4K bytes. That allows lengths up to 4GB. Gah4 ( talk) 06:29, 9 July 2020 (UTC)
In the opening section there's a sentence containing, "it is an attribute of a computing machine resp. its hardware architecture"
What does this even mean? Can someone who understand the original intent please clarify and fix the text. I'd gladly do the edit, but can't parse what it's trying to say. mikro2nd ( talk) 09:25, 10 July 2020 (UTC)
@ Kbrose:
- Nomen4Omen ( talk) 18:24, 25 July 2020 (UTC)
@ Kbrose:
Questions over questions ! Are there other people who don't get your point ? - Nomen4Omen ( talk) 19:40, 25 July 2020 (UTC)
The current article section Endianness#Definition has problems. (I think this is what the previous talk discussion about the lede has wandered off into, but I haven't been able to usefully follow it.)
A possible cause of the problems (and confusion with the lede) may come from the section heading itself: "Definition". The definition of any article subject belongs in the lede; why does this article have it a separate following section? One good reason may be that the lede definition, though technically complete and accurate, isn't good for any layperson reader -- too full of jargon, implied context, etc. A good way to explain something like that is to give an analogy -- describing situations not precisely accurate or perfectly complete, but providing enough context to allow enough basic understanding to follow the rest of the subject information. It seems to me that's what this whole section is trying to do, with debatable success.
Before we focus on solutions to this section, can we agree on the goal? Should we change the name of this section to "Example" to do this? ("Analogy" might also accomplish this, but I think it's less engaging to a reader.)
Comments? -- A D Monroe III( talk) 19:00, 27 July 2020 (UTC)
Indeed, there is no example like "Hello world". But, IMHO, binary integer is classical enough. So I propose: ==The prominent example: binary integers== – Nomen4Omen ( talk) 07:03, 1 August 2020 (UTC)
The article states that "Danny Cohen introduced the terms big-endian and little-endian into computer science for data ordering, in an article published by the Internet Engineering Task Force (IETF) in 1980".
The IETF was only founded in 1986, it could not be the original source of publication. — Preceding unsigned comment added by HeidenChristenseun ( talk • contribs) 16:31, 20 September 2020 (UTC)
@
Vincent Lefèvre: OK, if you don't see (“don't see any relation with big-endian”) that the right shift of the byte sequence
(0x02, 0x01) >> 8
is a right shift (of the integer 513 resulting in 2) on a big-endian machine;
and the right shift of the very same byte sequence
(0x02, 0x01) >> 8
is a right shift (interestingly now of the integer 258, resulting in 1) on a little-endian machine, then I have to give up.
And I'm absolutely sure that I am not the first observer of this fact. But nevertheless, I am not at all interested in looking up the literature for former observers. –
Nomen4Omen (
talk)
13:08, 18 January 2021 (UTC)
Unix
(as already mentioned in the
article), and you shift it to the right on a big-endian then you get ␣Uni
(looking like a right shift), whereas on a little-endian you get nix␣
which is apparently a left-shift. –
Nomen4Omen (
talk)
15:03, 18 January 2021 (UTC)
@
Vincent Lefèvre:
It IS already mentioned in the
article. As a problem – i.e. a trap into which programmers already have fallen. And it tells us that only extremely few programmers have to write programs which have to deal with the problem – and extremely soon, namely during testing, will notice that there is a problem. But this problem is not presented in a systematic way in the article.
[By the way, do you know how RTL script is recorded in storage? On a big-endian machine? It is not easy to find that out. But there are good reasons for the assumption that the Hebrew bible is kept in storage starting with the thora at the low addresses. And because a right shift on a big-endian shifts into the high addresses this remains a right shift – and only on screen it appears as a left shift.] –
Nomen4Omen (
talk)
21:51, 18 January 2021 (UTC)
I'm tired of fighting this edit battle, but endianness is not just "bytes in a word" but rather describes arbitrary sets of bits within a bit vector. "Bytes within a word" is the most common use but this arbitrarily narrow definition does a disservice to our users. J.Mayer ( talk) 20:38, 13 November 2020 (UTC)
@
Cousteau: As far as I can find out in
Right-to-left mark#Example of use in HTML the first character of a Hebrew text appears on the right of the screen, but is recorded "first" (i.e. at the low address) in RAM. (See also the discussion one section higher with Vincent Lefèvre.) So the Hebrew bible would be held in storage starting with the thora at the low addresses. This would mean (as you say) "addresses increasing to the (screen-)left". But because the first char is the most significant one and is at the low RAM-address, this resembles the big-endian convention.
This would mean that right-to-left (RTL) languages do not have an intrinsic conflict in the (RAM-)big-endian systems!? And consequently have an intrinsic conflict in the little-endian systems!?
Or, in your words: "This conflict between the memory arrangements of binary data and text is intrinsic to the nature of the little-endian convention", and ―as we now know― is a conflict for languages written left-to-right, such as English, but also for RTL scripts!? ―
Nomen4Omen (
talk)
06:13, 28 April 2021 (UTC)
@
Cousteau:
@
Vincent Lefèvre:
Thank you both for your contributions.
I guess that much of the confusion is coming in by mixing up some reading or writing direction with the sequence of addresses in RAM or memory. As far as I can see, there are about 3 coordinates which are relevant in this discussion:
As far as I could find out, the reading, writing or "visualizing" (as
Vincent Lefèvre names it) direction has absolutely nothing at all to do with RAM addresses: texts stored in RAM have the character which is to be read first situated at the lowest RAM address (where it is impossible to visualize them) ― with the consequence that the coordinates relevant to endianness are totally unchanged by LTR or RTL scripting. (The direction in which things are displayed on screen is specified by extra
Right-to-left marks, located also in the computer memory.)
Whatever
Cousteau wanted to express with his insertion of "(On the other hand, right-to-left languages have a complementary intrinsic conflict in the big-endian system.)" it is wrong, because RTL scripts fit very well to and do not have a conflict with big-endian systems. (This kind of conflict arises only if one identifies the reading, writing or visualizing direction (on paper or on screen) with some recording direction in the RAM, an identification which seems to be very popular, but, in fact, is completely mislead.) −
Nomen4Omen (
talk)
08:02, 29 April 2021 (UTC)
od -x
program prints 16 bit words, such that the bytes of a word are in the wrong order. The VMS (hex) DUMP program prints the address in a column, with the ASCII values on the right, and read left to right, and the hex data on the left, read right to left. Some years ago, I went to a talk about RISC-V, where they handed out a (green) reference card. The instruction formats are written with the opcode on the right. It just looks weird to read instructions with the opcode on the right. (They are at lower address.) It is slightly easier to build a simple processor little-endian, such as the 6502. (Look at the 6502 CALL instruction for some fun), as addition, and so carry, is done LSB to MSB. But multiply and divide or done MSB to LSB, so it doesn't help on those machines. The 8080 is little-endian, as that is the way CTC designed the 8008. I suppose reading hex dumps is less common now, but it is still inconvenient for little-endian systems.
Gah4 (
talk)
08:27, 29 April 2021 (UTC)
References
Let's expose the points pertaining to the article:
So, as a concluding sentence of the paragraph Endianness#Byte addressing I find the previous
having more reality and relevance than your
But the truth is that plain text has nothing at all to do with endianness in its proper sense. And the interpretion of a hexdump cannot be the purpose of the article, everybody recommends to take a debugging course on that. ― Nomen4Omen ( talk) 14:07, 29 April 2021 (UTC)