Talk:Bitwise IO: Difference between revisions
Add comment about the "naturalness" of big-endian order
No edit summary |
(Add comment about the "naturalness" of big-endian order) |
||
(12 intermediate revisions by one other user not shown) | |||
Line 3:
: Hmm, strictly speaking it is not bit-oriented. It is rather a bit-stream interface to a byte-oriented I/O. Exactly because it is not bit I/O (as for instance a serial I/O is) you have an endianness issue here. So in your task you should specify whether it is big or little endian encoding of bits into bytes. Your code looks like big endian. Was it your intention? --[[User:Dmitry-kazakov|Dmitry-kazakov]] 18:28, 19 December 2008 (UTC)
:: It is bit-oriented, as common ''software'' (not my intention to drive serial hardware this way!) I/O can be, i.e. you think you are writing one or more bits, indeed they are sent only grouped by eight, since we can only write bytes (and no more of one byte per time, or we have surely endianness issues). For the endianness while computing, it could be a point, but here I can't see how, since endianness issues are related to how bytes are stored into memory. Let us take a 0xFF packed into a 16 bit word. It will be written into memory, on little endian arch, as 0xFF 0x00. But when you ''take'' it, you can consider it ''logically'' (I love big endian!) as 0x00FF and you can be sure that if you perform a left shift, you will obtain 0x01FE... If you write it into memory, you have again 0xFE 0x01 on LE arch. '''But''', if you shift left 9 time, you will obtain 0xFE00 with a carry (or whatever the status flag for a bit ''slipped'' away from ''left'' is called). Again, iff you write it into memory, and pretend to read it as ''sequencial'' bytes instead of word, you get an issue. Again, into memory it is 0x00 0xFE for LE arch. Luckly even LE processor handle data into registers in a more logical way!
Line 226 ⟶ 224:
::--[[User:ShinTakezou|ShinTakezou]] 18:10, 13 January 2009 (UTC)
::: As a small point: you said that most-to-least significant is the "natural" order, but I'd like to point out that that is only true in Western languages that are written left-to-right. In Arabic and Hebrew, decimal digits appear in the same order despite the surrounding text being read right-to-left, so the digits appear in least-to-most significant order. --[[User:Markjreed|Markjreed]] ([[User talk:Markjreed|talk]]) 13:12, 28 March 2024 (UTC)
== PL/I bitstring longer than REXX'... ==
Line 231 ⟶ 232:
because the input seems to be STRINGS followed by '0D0A00'x
[[User:Walterpachl|Walterpachl]] 20:22, 2 November 2012 (UTC)
[[User:Carl Johnson|Carl Johnson]]
|