Talk:Bitwise IO: Difference between revisions

← Older edit

Talk:Bitwise IO (view source)

Revision as of 13:13, 28 March 2024

1,118 bytes removed , 2 months ago

Add comment about the "naturalness" of big-endian order

Markjreed

1,480

edits

Revision as of 16:49, 3 September 2020 (view source) rosettacode>Pchelper4 m (→‎Real intention) ← Older edit		Latest revision as of 13:13, 28 March 2024 (view source) Markjreed (talk \| contribs) (Add comment about the "naturalness" of big-endian order)
(19 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) :Not entirely sure so take this as speculation: I do not think the endianess is dictated by the unit size, the byte in this conversation, of transmission between the parties involved. I think it is the transfer line configuration mode which dictates the endianess. Meaning if the caller sends the data to the receiver, in that mode if it is a half-duplex(one transmission per line in active-high state when active-low is engaged) FIFO(first in, first out like a pipe) it would be big-endian and LIFO(Like if a plane were boarded from back to front on departure, then front to back on arrival) would be little or vice versa. Further, if the communications line(modem: modulate/demodulate) was to have two signals sent down it at the same time(full duplex, not two wires though) and drain/tap (with a voltage regulator, resistor, etc) attached and fed back to each party to the communication, it could from the frequency, demodulate the information based on what it sent if it has a memory. Three or more could be engaged but then more transmissions would be required to negotiate the relevant information specific to the party and relative to the others. Ttables would need to be used to speed this process up, such as a standard transformation of information or, if the complete use of the connection were to be known(closed, implying lost/misinterpreted data if this is incorrect), then every transmission could be 1:1 or I guess they say O(n). I guess this would be represented internally by processes or threads but that I feel is inaccurate. --[[User:pchelper4\|pchelper4]] 11:47, 3 September 2020 (CST) :: 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]]