endianness and bit shifting

[Dino]

I did some searching on this forum in ref. to endianness, and some of the posts are quite entertaining (quote brewbuck - of thigh-slapping hilarity).

Anyway, the point in a few of them is endianness is not left or right, but least significant and most significant. I'll buy that.

But, who forgot to tell the people that defined the bit shift operators? They are defined as shifting left and shifting right, not towards significance or away from significance (whatever that might actually mean in English).

My Mac is an Intel, and I have determined it is little-endian. I am processing data from an IBM mainframe, and that data is big endian. Writing the conversions for integers, I have figured this all out - no big deal in the end (no pun intended).

But, back to the bit shifting operators. It appears we get to think "big endian" at all times when using the bit shift operators, and ignore the actual endianness of the machine. Is this correct? (bit shifting for integers, that is)

Todd

[matsp]

No, shifting right always ends up with "smaller numbers" (less significant) and shifting left least to "bigger numbers" [assuming we don't "loose" any digits falling off the left edge].

So when it comes to bit-shifting, endianness doesn't matter [as long as you are shifting the number in one unit].

It's only when reading/writing memory that endianness makes a difference - the bytes from a big number either go out "big end" or "little end" first.

But bitshifting shuffles bits within a register in the processor, and left is always high end and right is the low end here, no matter which endianess the system uses.

--
Mats

[Dino]

So, I was correct, I just used the wrong term.

It's not that we're thinking "big endian" when a value is in a register, it just that it so happens that a value in a register would "map" byte for byte to the storage location it came from on a big endian machine, whereas on little endian machines the 4 bytes are reversed when in memory from when they are in the register.

Got it. Thanks for the confirmation.

[CornedBee]

Since registers don't have sub-addresses (maybe a sub-part has a name, but that's different), it's wrong to say that the data is reordered when reading/writing memory. They simply have no order in the register - they're treated as a single larger entity. Only the bits have an order - almost universally big-endian, because when you write down the entire number, you'll want it in the order humans are used to - but even that matters only for the shift/rotate left/right instructions, and nothing else.
The data is split into bytes on reading/writing and given BE or LE order.

[matsp]

Pedantic detail: And of course, the "left and right" in shifting is only valid when we write the number down on paper in arabic order (high bits to the left). The registers inside the processor may be oriented in any which way physically!

--
Mats

[CornedBee]

Not to forget that the flip-flops are arranged on a 2d plane. So left and right might not even have meaning. Or you have to add back and front.

[brewbuck]

But, who forgot to tell the people that defined the bit shift operators? They are defined as shifting left and shifting right, not towards significance or away from significance (whatever that might actually mean in English).

"Left" means left with respect to Arabic numeral order, in other words, toward more significance. This is hardly, if ever, mentioned explicitly.

You actually have gained an insight that a lot of people have trouble grasping. There is no spatial order to the bits of computer memory, or at least, whatever spatial ordering exists is irrelevant. The shifting terminology is so entrenched that people begin to try to imagine bits somehow being to the left of, or to the right of, other bits.

But, back to the bit shifting operators. It appears we get to think "big endian" at all times when using the bit shift operators, and ignore the actual endianness of the machine. Is this correct? (bit shifting for integers, that is)

I suppose you could think of it that way. But in practice the terms refer to the ordering of bytes within values which are larger than a single byte. Not individual bits.

Unless you are sourcing or sinking data from a byte-oriented channel, the question of endianness should not enter your thoughts.

[Dino]

Unless you are sourcing or sinking data from a byte-oriented channel, the question of endianness should not enter your thoughts.

I am. Sort of. I have binary mainframe EBCDIC files I am converting to ASCII TEXT on a Windows machine to be loaded into Oracle (and I'm doing all my development on a Mac - go figure!)

IBM Mainframes are big endian. Intel is little endian. When converting binary integers from the MF, a value of 0x01020304 has to be converted to 0x04030201 in order to format properly using C++ stream conversions.

The other conversion I've already done is packed decimal - a binary coded decimal format that has a trailing sign nibble and an implied decimal point.

The last one to do will be floating point. Not looking forward to that one.

I've defined a union to use when swapping the bytes around for the integers. Works great.

Thanks, Todd