Does endianness apply to bit order too?

Question

I haven't found a specific question here on SO, if this is a duplicate please point it out to me and I'll delete this.

So really, does endianness have anything to do with bit order?

This seems to imply the answer is NO, while other sources (I fail to find one right now, but surely I've read some time ago some articles) imply that endianness is the order of bytes and bits.

To be more specific: in a Big Endian architecture, where MSB is first, inside any byte, is also MSb first? Conversly, on Little Endian systems, where LSB is first, is LSb also first?

LAST EDIT: I found this which says "Bit order usually follows the same endianness as the byte order for a given computer system"

Historicism

I think it would be appropriate to choose a solution by now, since it seems several people here have given well-thought-out answers. – Darton

@user2752635 but all of these answers are bad! – Trahan

Answer 1

The other responses are not completely accurate. Yes, memory is byte addressable, so usually endianness stops there. But addressability isn't the only way to create well defined endianness.

In C, you can define bit fields. Bit fields have particular layouts; for example, the first bit field, if one bit, could be stored in either the msb or the lsb, and wrapping bit fields across byte boundaries in a big endian way is strikingly different than doing so in a little endian way. So if you define bit fields, you may have bit endianness.

But how these are arranged would have more to do with the compiler than the architecture, at least as a rule.

Astronomy

Answer 2

Endianness applied to only byte order. Not for bit order. The bit order remains same.

Why?

Memory is byte-addresseable. This is just a fancy way of saying that each address stores one byte. So You can change the order of bytes, not bits in memory.

Endianness only makes sense when you want to break a large value (such as a word) into several small ones. You must decide on an order to place it in memory.

Endianness only makes sense when you are breaking up a multi-byte quantity, and attempting to store the bytes at consecutive memory locations. But if you take in a register, it doesn't make sense. A register is simply a 32 bit quantity(depends on your processor/controller) and endianness does not apply to it.

Bit order usually follows the same endianness as the byte order for a given computer system - It is True

For more info Endianness

Languorous

Answer 3

No, simply because you cannot address bits individually.

Skeie

When working at the Hardware level (serial ports) then bit Endiannessis relevant.. and it is called bit Endianness.. – Primine

What about bit fields in structures? – Cesaria

@mafso, bytes are still the smallest addressable entity, which means the compiler will have to make use of bit shift operators to access bitfields in structs. – Skeie

Found it. C11 (n1570) 6.7.2.1 p.11 The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. Of course, the cases where you have to care, are rare, but do exist. – Cesaria

Even though you can't address bits, it is useful to know that the bits are still ordered in a certain pattern (i.e. one bit is considered more significant than the others). en.wikipedia.org/wiki/Bit_numbering – Darton

Counter example: "cannot address bits individually" is true, yet with bit-fields, bits can be accessed individually or in sub-byte size. Crafted (not so portable) code playing with the order of bit field members overlayed in a union are impacted by bit-endianness. – Odey

@chux not so. Endianness is how hardware manipulates multi-byte words. Bitfields are strictly a compiler thing that has nothing to do with hardware. – Skeie

Agree bit fields are a compiler thing, yet disagree how a processor indexes it bits has no influence on bits used with C's bit fields. For "has nothing to do with hardware" to be true C would specify that. Instead C has "The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined.". This certainly allows an compiler to vary its bit-field bit selection implementation based on any bit-endianness – Odey

Answer 4

In modern computing endianness only applies to ordering of bytes, not bits.

Veritable

Answer 5

Little-endian CPUs usually employ "LSB 0" bit numbering, however both bit numbering conventions can be seen in big-endian machines. Some architectures like SPARC and Motorola 68000 use "LSB 0" bit numbering, while S/390, PowerPC and PA-RISC use "MSB 0".[2]

please see

http://en.wikipedia.org/wiki/Bit_numbering

http://en.wikipedia.org/wiki/Most_significant_bit

Bloem

Answer 6

Looking back at this question I asked some years ago, today I can add a partial response with an example where bit endianness exists and is important: in communication protocols. Any protocol specification needs to define which bit is sent first when an octet is pushed in a bit stream.

Historicism

That's certainly true, but what does this have to do with architecture? JTAG, for example, requires data transmission in bits; when tapping the bits in along a JTAG chain, you must shift it in little endian (because it shifts in from the MS bit side). However, this requirement has nothing to do with your architecture nor your compiler; JTAG bits are sent little endian whether you're on a 32-bit Pentium 2 or a 64-bit power pc using big endian. – Astronomy

Nothing to do with the architecture. I just mentioned it as an example where bit endianness may be relevant (see my question title) for a computing system. – Historicism

In your question I'm reading a paragraph that begins with "To be more specific", not "For example". – Astronomy

(FYI I'm not arguing that this wasn't what you intended, but that if it was, then your question as it stands doesn't match your intended question and should be clarified). – Astronomy

Answer 7

What does "bits are not addressable" mean for dummies (like me and my students) ?

The smallest value/entity a computer can store/move/change is a byte = 8-bits. You cannot instruct it to read/write 3-bits, then 1-bit, then 11-bits, and tell the computer to memorize them as separate values. No, it only handles single bytes or byte packs/ranges.

Then the whatever application/process/hardware can play around with the bits inside a byte (or a native integer type, always a multiple of a byte).

Yet, once done playing, the stored values in memory/storage are still by "range" of bytes, which each single BYTE value - despite having their bits modified - gets directly updated with their new value at BYTE level.

That means, unless you build processors, you only actually deal with bytes, 0-255, period.

In records ? yes. Memory address ? yes. File data/stream ? yes. Network transfer ? YES GodDAMMIT !

As an example : lets say I'm on my LittleEndian computer having a 3 bytes (24-bits) record in memory in my application :

structure Test24 {
    var16 : 0xC1D3, // 49619 = 1100 0001 1101 0011
    var8  : 0xCA    //   202 = 1100 1010
}

Record that I save raw in a file, which I pass on to a buddy, on his BigEndian machine. What he gets on his machine upon loading the record in the same application is :

structure Test24 {
    var16 : 0xD3C1, // 54209 = 1101 0011 1100 0001 (bytes swapped)
    var8  : 0xCA    //   202 = 1100 1010 (same value)
}

The var16 is slightly different (corrupted), but that's because I didn't code my application to handle IO datas on a BigEndian architecture. He does not get the following record though where the bits gets entirely swapped :

structure Test24 {
    var16 : 0xCB83, // 52099 = 1100 1011 1000 0011 (bits swapped)
    var8  : 0x53    //    83 = 0101 0011 (different value)
}

^^ and that's because the file is read bytes-by-bytes, not bits-by-bits.

That's what "bits are not addressable" implies.

---

Student : But why are people being fancy about LSBit (LSB-0), MSBit, sometimes bit-endianness, like "it's very important knowledge" ?

Because that way of calling the bits actually gets the endianness concern out of the equation. Use the meaning of things in the right way, at least, use logic. The misunderstanding arises when we mix up talks about data, and talks about (processor) architecture. They-are-un-re-la-ted !

A data requires a context, like "this byte at this address contains the eight flags defining your access privileges on the system". That's NOT endianness concerns, that's what a bit at a given index is used for in the context of a defined data.

We, humans, are trained to read horizontally. But here is the problem :

What is byte 241 ? How we may represent what it contains ?
perhaps on little endian, LSB-0 on the left (?)
bit index : 0, 1, 2, 3, 4, 5, 6, 7 => 10001111b ?
or on big endian, LSB-0 on the right (?)
bit index : 7, 6, 5, 4, 3, 2, 1, 0 => looks more intuitive 11110001b

STOP SHOOTING YOURSELF IN THE FOOT ! Consider looking at it this way :
LSB 0 <- see : here it is, it doesn't matter where it is, it's just there
    1
    2
    3
    4
    5
    6
MSB 7 <- and here the other one, on the opposite side.

or this way :
MSB 7
      6
        5
          4
            3
              2
                1
                  0 LSBit

It doesn't matter where LSB-0 MSBit are as long as one is on the opposite side of the other. Get endianness out of the way ! Use the LSB-0 term to fix the start of your data encoding.

^^ now when you define "data flags order start at LSB-0", the flags being, "directory open, open pwd protected, directory copy, copy pwd protected, directory write, write pwd protected, directory delete, delete pwd protected", that means :

LSB 0 directory open
    1 open pwd protected
    2 directory copy
    3 copy pwd protected
    4 directory write subitem
    5 write to pwd protected
    6 delete subitem
MSB 7 delete pwd protected

So a byte value of 241 = LSB-0 : 1, 0, 0, 0, 1, 1, 1, MSB : 1 means

LSB 0 = 1 -> you can open directory
    1 = 0 -> directory access is not password protected
    2 = 0 -> you cannot copy directory
    3 = 0 -> noop
    4 = 1 -> you may create files or sub directories
    5 = 1 -> but a password is required to create file or dir
    6 = 1 -> you may delete the things in the directory
MSB 7 = 1 -> but a password is required to delete

There is no endianness involved at bit level when it comes to data, only bit position matters when you give a meaning to the value of a byte, and LSB-0 is always 0x01, no matter it's a big endian machine or a little endian one.

Byte values has nothing to do with how the machine treats a bit, most significant or not. So when you ask "could my data gets corrupted ?", noone should talk about MSBit or LSBit on the left or on the right. If you ask "what are the most volatile bits on this CPU ?", there you go, LSB/MSB positions is right in the middle of the talk (but are you into processor engineering ?)

---

• The actual SO question here is not how most architectures are assumed to behave (memory addressing), or can/cannot do, that, we should ask over Theorical Computer Science or Software Engineering.
• the real underlying question is when the data produced by my application, when it goes through network, IO, COM, hardware, whatever, gets its bits swapped, or gets corrupted when I failed to handle bit-order in my application.

Answer is : that doesn't happen, as long as you are not writing ROM data at hardware level, and you care about endianness at BYTE-level ONLY, when transferring data through different architectures/protocols. People are confused because of unnecessary endianness drama, and that endianness-thing is lurking where it should not.

---

At least, that's why I'm here, for students to start understanding what matters for a given challenge/concerns. They wouldn't be here if they already knew. Most people only have either little endian computer, or big endian, and don't have the privilege to cross check. They just don't know for sure, they get here via google and "bits are not addressable" errrmm... what ? what does that mean ? Should I swap my game data at byte or bit-level to be read correctly on all platforms or not ? I still don't know :/ That's the underlying reason why one would ask. Beyond the technical fact "bits are not addressable", there are that don't have the background to fully grasp the implications of such statement.

You only have to care about byte-endianness in the very rare case you actually encode your own made (or company specified) binary data through your application via your proprietary or borrowed stream read/write logic.

Don't want to handle endianness, use engines/frameworks with built-in read/write (like databases, clouds, etc.) or go plain text such as Json or XML.

Deodar

What about bit shift operations? They specifically shift left or right, so for them you need to care about bit order, no? – Counseloratlaw

@Counseloratlaw : You actually have TWO endianness layers, one at hardware level, the electron physical configuration inside a component, and the data/value level the one we should focus on here, a virtualized, abstract output from the component, or processor, or system, the value you are manipulating, the one you have on memory/screen. A value of 0x01=1 should be always represented as 00000001b, MSB, as a widespread convention, to make it easier for human brains to visualize, but you don't have any actual geometry. So when you shift left, it becomes 0x02, but it's all an imaginary concept. – Deodar

Trying to enforce a geometry layout on a non physical concept is VERY confusing. If you are in component engineering, obviously you must design how electrons translates to an usable value in ROM/Processors/Memory/Code : you engineer a LSB component, meaning, by design, writing an abstract value of 0x01 (data side) translates into storing electrons as 0x80, but the component must still output a value of 0x01. How the component manages to do that, we don't care. This works as long as you are not going outside of the component/system domain. Don't get confused by the two layers. – Deodar

Now, what's the point of MSB/LSB at data level ? Because the world didn't agree from the start on hardware norm, LSB OR MSB, you have both. So, when you exchange informations between systems, like via a network wire because by coding your values in memory as a byte stream (electrons), well, the bits may get swapped, not because there is a bit geometry at value level of your byte array, but because your byte array has been converted to a specific electron configuration by a component, and converted back to an imaginary byte array by ANOTHER component. Do you start to understand ? – Deodar

When you are aware you are exchanging data between different systems without native endianness support, you are responsible of intentionnaly serializing FAKE values into COMPATIBLE electrons configuration output-end, by swapping the (virtualized, imaginary, practically non-existent, conceptual) bits. That's one thing. Manipulating bits with shifts, or/and/xor in order for the value to have a MEANING and be useable for we humans, is a whole another thing : if you require the "bits" to be a certain order, yeah, having a conceptual representation of bit positionning helps (MSB) – Deodar

Don't get confused, define first what you are dealing with, if you are at risk to interact with different systems at data level. If you are just using int, bool string as-is, without encoding/serializing anything, inside the boundary of the system endianness, don't bother. If you use bit flags, interpret values as MSB geometry and use the bits manipulation tools accordingly. If you go beyond system endianness, swap the bits whenever applies. If you are designing components, make sure you output the expected value whatever the way you write/manipulates electrons. – Deodar

Answer 8

Endianness works on the basis of bytes not bits. Bits are not addressable.

Keratogenous