5
$\begingroup$

What I can't wrap my head around is sentence repeated everywhere I look, that order of bits in byte is not important(not of my, as a programmer, concern). My question then is if there is possibility that it makes difference?

For example, I crate a binary file with just 0x1 in it (represented on my machine as 00000001). What keeps other machine to read the same byte as 128(10000000) ? Is there standard for msb placement in file, memory that guarantees compability or am I missing something trivial/obvious along?

EDIT: Thanks to dirk5959's answer I found out that my machine is little-endian for bytes and the same is for bits in byte. Additional question is, if it is a rule or there is some architecture that behaves different?

$\endgroup$
  • $\begingroup$ 0x01 is defined as the least significant bit in the byte. So if the order is 10000000 it's still 1 not 128 $\endgroup$ – slebetman Dec 18 '14 at 2:18
9
$\begingroup$

Bytes are transferred from memory to disk using an I/O protocol (e.g. SCSI) that specifies the bit order of transmission in the case of a serial protocol, or for parallel protocols specifies which pin upon which each bit in a byte should be transmitted. For bytes moved from memory over the network, the network link level protocol (e.g. Ethernet) specifies the bit order. In either instance, an application programmer need not concern herself with the details; the operating system in concert with disk or network controllers will maintain the correct bit order end-to-end so that the correct values are transmitted/received or store/retrieved.

N.B.: byte order is another matter altogether.

$\endgroup$
  • $\begingroup$ Thanks to your answer I managed to pin what really bothers me. What about transferring raw data, without usage of network, but let's say CD or FLASH or even whole HDD swap. Is there guarantee that the exact representation of my binary file on another machine represent the same decimal values byte by byte? $\endgroup$ – zubergu Dec 17 '14 at 23:00
  • 5
    $\begingroup$ Disk drives have controllers that ensure bits are read and written in the same order. Removable media like CDs and DVDs are written according to data encoding standards that ensure interoperability between devices. The standards specify layout of the data down to the bit level, including error correction information. $\endgroup$ – Kyle Jones Dec 18 '14 at 1:15
6
$\begingroup$

Your sources are probably referring to the fact that, as a high-level programmer, you usually can't access the machine representation of bits in a byte. Even when you perform bitwise operations (like bitwise and or shift) you're manipulating standard binary representations of bytes, not necessarily the bit representation of bytes in your computer.

See https://stackoverflow.com/questions/16803397/can-endianness-refer-to-bits-order-in-a-byte.

$\endgroup$
  • $\begingroup$ thanks for the answer, I checked the union from your link and my bit endianness is opposite to what I supposed it was, so 1 is actually lsb 10000000 msb. The question how is compatibility achieved between other machines that do the opposite remains open. $\endgroup$ – zubergu Dec 17 '14 at 22:28
2
$\begingroup$

Basically, if you are programming at any level higher than assembly then you do not need to care (with really few exceptions) about the order of bits. Files' structures and number representation in the CPU are separate things. In general it is CPU's (or its IO system's) job to prepare the numbers for operations and save them in a way the programmer wants it to.

Little-endian machines got quite popular as there are some bit-wise tricks that are easier to perform with such representation. However, there are many processors with other approaches. While x86 are typically little-endian, ARM processors often have the selector, so the programmer can choose if they want numbers to be represented in little or big endian.

Anyway, any level of abstraction higher than assembly takes care of converting the numbers from human-desired to CPU-understanded way and back again. And you should not mess up low-level stuff into high-level concepts unless it is absolutely necessary (and it rarely is.)

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.