Talk:Endianness

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Networking / Hardware (Rated B-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (marked as Mid-importance).
Taskforce icon
This article is supported by Computer hardware task force (marked as High-importance).
 

bytes or digits[edit]

Endianness in computing is similar, but it applies to the ordering of bytes, rather than of digits. It is usual today for endianness to apply to bytes. It can also apply to other bit groups. How are decimal numbers stored for the Intel 4004? Gah4 (talk) 17:43, 29 September 2016 (UTC)

BCD Little-endian. Either unpacked (where each digit takes up an entire byte, the top four bits being wasted) or packed (low-order nibble is least significant digit). Intel 4004 architecture manual. --jpgordon𝄢𝄆 𝄐𝄇 18:04, 29 September 2016 (UTC)
The link seems to be for more modern IA (Intel Architecture), and yes IA allows for either packed or unpacked bytes. But the 4004 uses four bit data, so big/little endian should be based on four bit decimal digits for BCD data. Gah4 (talk) 05:18, 30 September 2016 (UTC)
I changed it to usually which is probably close enough. Gah4 (talk) 05:21, 30 September 2016 (UTC)
And, for fixed point, packed decimal big-endian on IBM System/360 and its successors, all the way up to z/Architecture; the high-order digit is in the upper 4 bits of the byte and the low-order digit is in the lower 4 bits of the byte. See page 34 of the first edition of the System/360 Principles of Operation. Guy Harris (talk) 07:23, 30 September 2016 (UTC)
I'm not sure the example of endianness really fits for most people's perception. We write the most-significant digit first, but we operate on them going the other way. Cognitively, operating is a "more important" activity than writing, and we generally grade things by their importance. (I trained in psych, not csci). 98.118.17.206 (talk) 20:14, 17 October 2016 (UTC)
With respect to direction there are two kinds of «operations»:
  1. addition, subtraction, and multiplication go from low to high order
  2. division and comparison go from high to low order.
One should not totally ignore the latter 2 «operations». --Nomen4Omen (talk) 21:03, 17 October 2016 (UTC)
Yes. Architectures that started out without a divide operation had some tendency to be little endian. Ones that included divide from the beginning, such as IBM S/360 and Motorola 680x0. For many years, programs were debugged from printed hexadecimal storage dumps, which are re easier to read in big-endian form. Gah4 (talk) 06:34, 18 October 2016 (UTC)

XDR[edit]

there is no formal standard for transferring floating point values between diverse systems There is External Data Representation as a standard for transferring data, including floating point, between diverse systems. Maybe not quite as popular is it should be. Gah4 (talk) 19:18, 29 September 2016 (UTC)

Well, XDR just falls back on IEEE 754 for floating point, which indeed doesn't specify endianness. Perhaps you might do some rewording. --jpgordon𝄢𝄆 𝄐𝄇 03:57, 30 September 2016 (UTC)
IEEE 754 doesn't define endianness, but XDR does. In either fixed or floating point, XDR is big endian, even when transferring between two little endian hosts, and IEEE 754 even if one or both hosts don't use that format. But mostly, I consider XDR a formal standard. I haven't thought of new wording yet, though. Gah4 (talk) 05:13, 30 September 2016 (UTC)

This is the way a hexdump is displayed: because the dumping program is unable to know what kind of data it is dumping,[edit]

The VAX/VMS (and maybe other VMS) DUMP program displays ASCII characters with the address increasing to the right on each line, and hex data with the address increasing to the left. That is, it knows numeric vs. character data. Gah4 (talk) 03:11, 31 October 2016 (UTC)

No, it doesn't. It just dumps all of the requested locations. Bytes that happen to contain printable ASCII characters are displayed that way, and hex data is displayed as makes sense for little-endian because that's how the VAX implements binary integers. But the DUMP program does not "know" which bytes will be interpreted as which sort of data. If it did then it would not display a longword containing 0x64636261 as ABCD in the text part of the display.
And yes, VMS on the Alpha does the same thing. ia64, I dunno. Jeh (talk) 04:17, 31 October 2016 (UTC)
Yes, I put the knows in quotes because, as you note, it doesn't actually know. But people would be really surprised if the ASCII data printed backwards. Another explanation is that it assumes that numbers are little endian, and text is big endian. Now, there is still Unix's od -x which prints hexadecimal 16 bit words, so they come out in the wrong order as sequential bytes on little endian machines. Gah4 (talk) 05:18, 31 October 2016 (UTC)
I have an RX2600. If I renew the hobbyist license, I could test it out. Gah4 (talk) 05:18, 31 October 2016 (UTC)

Recommendation for new section: Endianness in natural language[edit]

I'd like to see a section on endianness in natural language, namely a survey of world languages accompanied by notes re: any patterns that appear to apply worldwide or region-wide, but I am not familiar enough with a wide enough variety of the world's languages to draw any conclusions myself. My guess is that this section would benefit (even more than usual) from having a subject-matter expert involved from the start.

Here are my (non-expert and possibly wrong) observations so far:

  • Numbers:
  • Spoken and transcribed from speech:
  • Uniformly big-endian:
  • Japanese, at least from what I remember from martial-arts classes
  • Korean, [ditto]
  • Mixed throughout based on place order alone, i.e., regardless of value within place:
  • German, following most-least-[and-]middle value-place order within each set of three value places (corresponding to each group separated by short-scale commas when numerals are used), i.e., hundreds-ones-[and-]tens order both for three-value-place numbers and for designations of value in higher places, as in siebenhundertsechsundneunzigtausenddreihundertvierundzwanzig (796,324)
  • (possible) Early Modern and older English: Does the "four and twenty blackbirds baked in a pie" pattern apply when the 24 value units being enumerated are thousands, millions, short-scale billions / long-scale milliards, short-scale trillions / long-scale billions, etc.?
  • Mixed throughout when certain places have some values but not when they have others:
  • "Modern" Modern English, following most-least-middle order within each set of three value places when middle value is one but most-middle-least order (i.e., "pure" big-endianness) otherwise; contrast "eight hundred fifteen thousand, four hundred seventeen" (815,417) with "six hundred twenty-four thousand, nine hundred fifty-two" (624,952)
  • Uniformly little-endian:
  • None that I know of; I'd be especially grateful for an example here
  • If there are in fact no languages anywhere in the world that employ pure little-endianness in speech or transcription of speech, might that fact be a clue showing how, or more precisely ruling out one possibility for how, the brain processes numbers?
  • Written in numeral form:
  • Uniformly big-endian:
  • Indo-Arabic, at least when used in languages that read from left to right...
  • ... But are there any right-to-left writing systems that use Indo-Arabic (as opposed to Eastern Arabic) numerals, and if so, then for each such system, does it maintain the left-to-right aspect, thereby switching the endianness to little-, or does it maintain big-endianness, thereby switching the order to left-to-right?
  • Mixed:
  • [Are there any of these among "true" numeral systems? The use of numerals would seem to have among its purposes the ease of sorting in one direction or another...]
  • (exclusion) I'd argue that Roman numerals don't fall into this category because the placement of smaller numbers out of order denotes not the presence of their value but rather the absence (i.e., "to-be-subtractedness") of that value from the following number placed according to big-endian rules.
  • Uniformly little-endian:
  • Eastern Arabic: Text is read right to left; numerals are read left to right.
  • Dates:
  • Spoken:
  • Uniformly big-endian (year-month-day):
  • [Question: Do East Asian languages that employ year-month-day order in writing also do so in speech?]
  • Middle-little-big (month-day-year):
  • American English
  • Uniformly little-endian (day-month-year):
  • Modern western continental European (not sure about modern British English or Slavic languages)
  • Written:
  • Uniformly big-endian:
  • At least some East Asian languages (I'd need an expert to confirm which varieties of which languages)
  • Middle-little-big:
  • American English (majority practice)
  • Uniformly little-endian:
  • Modern Western European, including British English (not sure about Slavic languages using Roman alphabet or about languages using Cyrillic alphabet)
[Question: Have any studies been done about the relationship, if any, between use of endianness in date numbering and the time horizon for the context in which it is used and/or the on which people typically think in the cultures using it in everyday life? Little-endian ordering is most efficient if everything is to occur within the remainder of the current calendar month or occurred within the portion of the current calendar month elapsed to date, but middle- (month-)first endianness is helpful if one is making broad, non-granular plans for a calendar year, and big-endianness is necessary for long-term archival in chronological order and long-term future plans. I wonder whether the date order in common use in an area cognitively primes the people who use it to think on a certain time scale.]

Thanks!

Antediluvian67 (talk) 19:08, 23 February 2017 (UTC)