This is an old revision of this page, as edited by Kvng (talk | contribs) at 15:37, 8 December 2023 (→Potentially problematic edits: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Revision as of 15:37, 8 December 2023 by Kvng (talk | contribs) (→Potentially problematic edits: new section)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)This is the talk page for discussing improvements to the Endianness article. This is not a forum for general discussion of the article's subject. |
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later. |
This article has not yet been rated on Misplaced Pages's content assessment scale. It is of interest to multiple WikiProjects. | |||||||||||||||||
Template:Vital article
Please add the quality rating to the {{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details.
|
Archives | |||||||||
Index
|
|||||||||
This page has archives. Sections older than 60 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present. |
Most/least significant byte definition
Most significant byte and least significant byte are used at the start of the article without much reference as to what they mean. They are linked to a page which redirects to "Bit numbering#(Least|Most) Significant Byte" as of right now, but those sections no longer exist on that page. appears to be the revision that got rid of those sections, and in it's edit summary it points to the Endianness article to define these terms. Those redirects should be changed, but the information might want to be inserted in this page, which is why I'm leaving this on the talk page. 2001:48F8:7054:18FA:0:0:0:7297 (talk) 01:34, 30 March 2022 (UTC)
- Hmm. How else would you describe it? In a numeric system, the 100's digit is more significant than the 1's digit, which is the sense meant. Is there another word that indicates this? Gah4 (talk) 22:41, 5 April 2022 (UTC)
- 2001:48F8:7054:18FA:0:0:0:7297: The problem with the missing section names has now been corrected. All that was needed was to add a couple of {{anchor}} templates to the target article, which I've done. Endianness doesn't need to change. -- R. S. Shaw (talk) 01:21, 6 April 2022 (UTC)
Predominant addressing scheme
The subsequent section "Calculation order" has the sentence:
- Addressing multi-digit data at its first (= smallest address) byte is the predominant addressing scheme.
So it is possible that a machine has another addressing scheme. With such an addressing scheme the statement of the section "Simplicity" becomes false. –Nomen4Omen (talk) 20:42, 25 April 2022 (UTC)
- What other such addressing schemes exist? That scheme is used for all byte-addressable binary computers that I know of.
- Perhaps for decimal data that takes multiple storage locations there are machines where instruction operands refer to the last storage unit rather than the first storage unit; are there?
- If they do exist, then the notion of different ways of addressing multi-storage-unit data as operands, distinct from endianness, should probably be introduced separately, before either § Simplicity or § Calculation order. Guy Harris (talk) 21:14, 25 April 2022 (UTC)
- As noted in a {{note}}, the IBM 1401 does addition from high address to low address. As long as one is consistent, it doesn't make all that much difference. Computers can usually subtract about as easily as add. In the case of the 6502, it is data in the instruction stream that is conveniently little endian, as the instruction counter increases. The 6502 is funny, in that the CALL instruction does not put the return address on the stack, but one less than the return address. It seems to be what is in the PC at the time. (RET has to fix this.) Gah4 (talk) 21:21, 25 April 2022 (UTC)
- Also, early Fortran compilers stored arrays in decreasing addresses in memory. This might have been related to indexing operations on the IBM 704. Gah4 (talk) 21:31, 25 April 2022 (UTC)
OK, so now:
- § Basics says "On most systems, the address of a multi-byte simple data value is the address of its first byte (the byte with the lowest address)."; that's the sentence to which the note about the 1401 is attached.
- § Simplified access to part of a field begins with "On most systems, the address of a multi-byte value is the address of its first byte (the byte with the lowest address); little-endian systems of that type have the property that, for sufficiently low values, the same value can be read from memory at different lengths without using different addresses (even when alignment restrictions are imposed)." (I expanded the name - "Simplicity" is a very broad term, and this is simplification of a very specific thing.)
- § Calculation order says "Addition, subtraction, and multiplication start at the least significant digit position and propagate the carry to the subsequent more significant position. On most systems, the address of a multi-byte value is the address of its first byte (the byte with the lowest address); when this first byte contains the least significant digit – which is equivalent to little-endianness, then the implementation of these operations is marginally simpler."
Hopefully, that makes things clearer. Guy Harris (talk) 02:56, 26 April 2022 (UTC)
- I wouldn't have put in multiplication, which is not simple in any order. In the case of the 1401, operands are variable length. Also in the case of the 1401, you want them in big endian order for printing. The 6502 is an amazingly simple processor, so even marginally simpler is enough. Gah4 (talk) 04:59, 27 April 2022 (UTC)
- I didn't put in multiplication - it was already there; all I did was replace "The address of such a field is mostly the address of its first byte." with "On most systems, the address of a multi-byte simple data value is the address of its first byte (the byte with the lowest address)." Guy Harris (talk) 05:03, 27 April 2022 (UTC)
- Oh, yes, it wasn't supposed to say that you did. I had thought about it earlier, but didn't say it until then. Gah4 (talk) 06:57, 27 April 2022 (UTC)
- I didn't put in multiplication - it was already there; all I did was replace "The address of such a field is mostly the address of its first byte." with "On most systems, the address of a multi-byte simple data value is the address of its first byte (the byte with the lowest address)." Guy Harris (talk) 05:03, 27 April 2022 (UTC)
"Bytesex" listed at Redirects for discussion
An editor has identified a potential problem with the redirect Bytesex and has thus listed it for discussion. This discussion will occur at Misplaced Pages:Redirects for discussion/Log/2022 November 25#Bytesex until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Veverve (talk) 15:39, 25 November 2022 (UTC)
- It was relisted several times, ending up at Misplaced Pages:Redirects for discussion/Log/2022 December 9#Bytesex, which indicates it was closed as "Keep". Guy Harris (talk) 22:49, 7 January 2023 (UTC)
Bytesex?
Does the term "byte sex" deserve to be in the first sentence? It has about 60,000 bing hits, and most of the first page isn't even discussing it in the endian sense. I've never heard the term before. 2A00:23C5:321B:BB01:241C:9873:FD0F:C101 (talk) 21:26, 7 January 2023 (UTC)
- As above, it is in active discussion. Yes, I suspect it shouldn't be in the first sentence, if at all. Gah4 (talk) 22:24, 7 January 2023 (UTC)
- The removal of the "bytesex" redirect is no longer under active discussion. It was relisted several times, ending up at Misplaced Pages:Redirects for discussion/Log/2022 December 9#Bytesex, which indicates it was closed as "Keep". Guy Harris (talk) 22:48, 7 January 2023 (UTC)
- Just because the term 'byte sex' can redirect here doesn't mean this article should discuss it in the first paragraph. This is a bit of obscure historical jargon which is no longer in current use. At best it belongs in a footnote. –jacobolus (t) 18:18, 9 January 2023 (UTC)
- For all practical purposes the term is extinct, most younger practitioners will not recognize it, linux.bytesex.org notwithstanding, and we are WP:NOTDICT, so the lead is a bad place for this synonym (I have no objections against the redirect, and, most likely, some anchor in the text). I agree that even now the term is WP:UNDUE that high in the article, unless the section is expanded to cover much more widespread terms: "network byte order" is currently relegated to mid-article, "host order" is even lower and has no coherent definition whatsoever. Dimawik (talk) 05:28, 11 January 2023 (UTC)
- No objection for a month to the removal from the lead. Per Guy Harris I am changing it to an anchor so that the redirect will stay operational. Dimawik (talk) 08:43, 23 February 2023 (UTC)
- The removal of the "bytesex" redirect is no longer under active discussion. It was relisted several times, ending up at Misplaced Pages:Redirects for discussion/Log/2022 December 9#Bytesex, which indicates it was closed as "Keep". Guy Harris (talk) 22:48, 7 January 2023 (UTC)
Bit endianness
Regarding the removal of "bit endianness": the term is easy to find in the literature (e.g., , a book by Springer). The deleted text about the error-correcting codes was also factually correct (I expect it to be hard to find a source for the latter, though). I happen to like the new text more, and think that the error correction minutiae are out of scope here altogether, but, probably, it is worth adding back the "bit endianness" term somewhere in the text (not in the section header)? Pinging @Kvng: Dimawik (talk) 03:58, 25 April 2023 (UTC)
- Bit endianness is less of a problem, but still exists. Some hardware has the ability to address bytes. Even when it doesn't, hardware descriptions don't always number bits the same way. Yes it happens at a lower level, but for those working at that level, it is important. Gah4 (talk) 05:06, 25 April 2023 (UTC)
- Yes, anyone who tried to code bit fields in a portable way knows the problem well. The issue here is a terminological one: should we mention the term "bit endianness" or be happy with a more popular "bit order"? Dimawik (talk) 07:25, 25 April 2023 (UTC)
- Thanks for the comments. We do have a Bit endianness redirect (which I broke) so I should restore that (with a ref). There is Dimawik's question about preferred terminology here. Any opinions?
- There is discussion of bit order (and byte order) at Cyclic redundancy check so I think it would be valuable to restore that tie in. ~Kvng (talk) 13:49, 25 April 2023 (UTC)
Potentially problematic edits
Thumperward has recently made some bold edits. Some of these don't appear to be well justified. I have not reverted any of this yet.
- cite quotes are almost always pointless. I assume they're helpful to readers who don't have ready access to the cited source. What's the harm?
- one day people will get over this completely wrong-headed notion that any time a term might ever possibly refer to the current article, it needs to be bolded. Some of the boldface is per MOS:BOLDSYN and should be restored.
- ascii art is a bad way of representing anything, and the text should be clear enough already, likewise. text does a perfectly good job here. These are tables, not ASCII art. It is very often useful to have both visual and written descriptions as different presentations work better for different readers.
- just link this. I don't see a problem summarizing a closely-related topic here.
- more jargon file crap. A quick search finds NUXI problem in fairly widespread use. This may need to be tagged for a better citation. I don't think it should be removed. This bold edit also draws into question some of the work done a little earlier in ...remove "byte-sex" nonsense from ESR's jargon file, which is nothing more than ESR's own list of personal neologisms.
- cite needed, not code. So let's find a citation. Meanwhile, let's keep the code as provides some level of verifiability to anyone who knows the language in question. WP:DEMOLISH.
~Kvng (talk) 15:37, 8 December 2023 (UTC)
Categories:- All unassessed articles
- C-Class Computing articles
- High-importance Computing articles
- C-Class Computer networking articles
- Mid-importance Computer networking articles
- C-Class Computer networking articles of Mid-importance
- All Computer networking articles
- C-Class Computer hardware articles
- High-importance Computer hardware articles
- C-Class Computer hardware articles of High-importance
- All Computing articles