Endianness does not apply to byte

How can you tell the endianess of a byte if a byte is the smallest addressable unit of memory? I don't think you can.

I think the endianess of the smallest unit of memory is unknowable to the processor. In fact the processor couldn't detect how the memory is wired for the smallest addressable unit, i.e. it can't tell if d0 is connected to d0 or d8 of the memory chip. Nor does it care.

Fun to think about, though. ;-)

-Rich

Sorry, Data General and IBM mainframes have the MSB numbered '0'.

And GCC also has a setting for whether bits are big or little endian; it determines which end of a byte bitfields are allocated at. I.e:

struct { int i1:3; int i2:3; int i3:2; } foo;

Which bits are for i1?

Little endian make perfect sense when you have a processor that can handle multiple variable sizes such as the 80386.

On a 80386 you would declare your variable as

Var DW 1234h,5678h

And access it as mov al,Var ; byte size access or mov ax,Var ; word or mov eax,Var ; long word

if it had have been big endian then the same code would be mov al,Var+3 mov ax,Var+2 mov eax,Var Yuk. So, little endian wins in my book.

But then again, it's been a long time since I worked in assembler. I might have even mixed up processors above!!

Mike.

PA-RISC also does this. What a pain in the ass it is, by the way. I worked with a chip that was essentially an i486 SoC where the 486 core was removed and replaced with a PA-RISC. All the CPU registers and bus lines were numbered in the MSB=right-hand convention. All the peripherals were numbered in the MSB=left-hand convention. Possibly the worst 32-bit micro I have ever used.

However it doesn't alter the fact that "big-endian" vs "little-endian" is by definition a discussion of _byte_ order, not _bit_ order.

...

The only good-endian is a dead-endian!

It is really strange that Endiannes is not dependent on the Bit_Order but only on the Byte_order.

Why, the Bit_Order has not been taken into consideration ??

Really strange. Any specific reasons for this ??? Eager to know about this.

Thx in advans, Karthik Balaguru

They aren't. You can't address bits[1]. Therefore, talking about what order they're in is nonsensical.

I've no idea what you're talking about. Are you referring to the format that a byte is printed on your terminal? If you don't like that, print it differently. It's got nothing to do with "endianness".

[1] There are some processors that can address bits within a register with certain instructions. All the ones I've see call the LSB bit "0". I've never seen such bit-addressing made visible in a high-level language -- except possibly PL/M-51 from Intel (I never actually wrote in PL/M-51, and have rather vague memories of it). The 8051 had a nifty feature where there was a block of memory that was bit-addressible. I don't remember if the bit addressing was big-endian or little-endian

I have seen documentation (IBM?) where the register desriptions label the MSB of a register as bit 0, but I've not run into any hardware that works that way.

--
Grant Edwards                   grante             Yow!  If our behavior is
                                  at               strict, we do not need fun!

Just like Bytes make the Most Significant BYTE(MSB) and LSB of many datatypes. The Bits make the Most Significant BIT(MSB) and LSB of a Byte.

It is strange that Endiannes is not dependent on the Bit_Order of a Byte but only on the Byte_order.

My questions are : Why bits of a byte are of Big-Endian type ? Then, we could have gone for Big-endian throughout all designs !!

Why did Little-Endian come ?

Why bits of BYTEs do not have endianness ? Just like bytes, bits are also manipulated in many places in the form of MSB and LSB only. Every basic driver level interface goes to the BIT level.

So, Why the Bit_Order has not been taken into consideration ??

Really strange. Any specific reasons for this ??? Eager to know about this.

Thx in advans, Karthik Balaguru

Thx in advans, Karthik Balaguru

Just like Bytes make the Most Significant BYTE(MSB) and LSB of many datatypes. The Bits make the Most Significant BIT(MSB) and LSB of a Byte.

It is strange that Endiannes is not dependent on the Bit_Order of a Byte but only on the Byte_order.

My questions are : Why bits of a byte are of Big-Endian type ? Then, we could have gone for Big-endian throughout all designs !!

Why did Little-Endian come ?

Why bits of BYTEs do not have endianness ? Just like bytes, bits are also manipulated in many places in the form of MSB and LSB only. Every basic driver level interface goes to the BIT level.

So, Why the Bit_Order has not been taken into consideration ??

Really strange. Any specific reasons for this ??? Eager to know about this.

Thx in advans, Karthik Balaguru

Haha. Please, please, let this thread come to a dead-end now.

Because on most machiens _there_is_no_such_thing_as_bit_order_.

[And no, the ordering of bitfields within a struct doesn't count.]

You can't index into a word like this:

unsigned u = 12345; bool b = u[0]; // is u[0] MSB or LSB of u?

AFAIK, the discussion about IBM and HP calling the MSB bit "0" is only relevent to documentation.

No, it isn't.

--
Grant Edwards                   grante             Yow!  Is something VIOLENT
                                  at               going to happen to a

[...]

OK, now you're just trolling.

--
Grant Edwards                   grante             Yow!  ... I'm IMAGINING a
                                  at               sensuous GIRAFFE, CAVORTING

What you don't seem to grasp and no one is explaining to you properly, is that endian-ness is not a function of the bits or the bytes, but of the *addressing*. Most machines can not address bits, so bits are not part of endian-ness. If a machine only addresses words and not bytes, it does not *have* endian-ness in any regard.

You are assuming that because a word is written as 00001, the 1 is in the right or least or last position. But this is not what endian-ness is about. It is about how the machine addresses the units. So endian-ness only applies when different sized units are addressed.

Is that more clear?

karthikbg wrote:

Is that convention visible to the programmer in any way? IOW, at the assembly language level are there instructions that use an integer "bit index" as an operand?

A completely fictitious example where bit "endianess" would be visible:

BITSET R0,#0 // Sets MSB of R0

MOV R1,#31 BITCLR R0,R1 // Clars LSB of R0

Off the top of my head, I can think of one CPU that has instructions like that (Hitachi H8), and it's "little-endian" when it comes to bit-ordering (bit 0 is LSB), even though it's "big-endian" when it comes to byte ordering (the most significant byte of a multibyte integeger has the lowest address).

--
Grant Edwards                   grante             Yow!  We just joined the
                                  at               civil hair patrol!

Yes, IBM refers to bit 0 as the MSB. Thus if you have a powerpc device (from IBM or Freescale), and look the pin numbering, D0 is the MSB of the databus and D31 is the LSB. It gets more fun with the address bus - if only 24 of the 32 bits are mapped to physical pins, then these are A8 down to A31. And if you really want to confuse yourself, try a 64-bit PPC device - the databus from MSB to LSB is numbered D-32 to D31, and an external 40-bit address bus would be from A-8 to A31.

Little-endian and big-endian come from Lilliput.

Thx for all your responses. It clarified my doubts.

So -> endian-ness is not a function of the bits or the bytes, but of the *addressing*. Most machines can not address bits, so bits are not part of endian-ness. If a machine only addresses words and not bytes, it does not *have* endian-ness in any regard.

Thx, Karthik Balaguru

Right. Think of it this way - when people say "endianness" they usually mean "byte endianness" - assume they're talking about the addressability of bytes within words, or words within multiwords, which can be different - Crays have "nuxi" endian - bytes are little endian within words, but words are big endian within dwords (er, or visa-versa). I think ARM FPUs can be too, because the CPU is one endian, which governs out to the data bus, but the FPU may be a different endian, which governs things larger than the data bus.

Some MCUs *can* address bits (the M32C can address the first 64k bits

*directly* and *absolutely*) and in those cases, you have to consider both byte endianness and bit endianness (for the M32C, they're both little-endian - the LSB of word 0 and byte 0 is absolute bit 0).

It can still have word endianness - consider a machine that addresses

32 bit "units". If you want to store a 64 bit value, you still have word endianness to consider.

Summary:

bit endianness - whether the lowest addressed bit is the LSB or the MSB of a byte (applies to structure bitfield layout and bit-addressing opcodes).

byte endianness - whether the lowest addressed byte in a word is the LSB or the MSB.

word endianness - whether the lowest addressed word in a multi-word is the LSB or the MSB.

"word" is often defined as "the size of our data bus" because that's where the difference (when there is a difference) often originates.

My guess is compatibility with previous processors. I.e. emulating an 8 bit cpu on a 16 bit LE cpu might be easier than on a 16 bit BE cpu.