84

Does endianness matter at all with the bitwise operations? Either logical or shifting?

I'm working on homework with regard to bitwise operators, and I can not make heads or tails on it, and I think I'm getting quite hung up on the endianess. That is, I'm using a little endian machine (like most are), but does this need to be considered or is it a wasted fact?

In case it matters, I'm using C.

Community
  • 1
  • 1
Frank V
  • 25,141
  • 34
  • 106
  • 144
  • 1
    Duplicate: http://stackoverflow.com/questions/7184789/does-bit-shift-depends-on-endianness – 0andriy Nov 19 '15 at 11:54
  • 4
    IMHO, these are slightly different questions. This question is like "is `128 << 2 == 512` on any CPU?", that question is like "does `128 << 2` lay out as `0x02 0x00` on any CPU?". – kolen Jan 02 '19 at 16:32

5 Answers5

86

Endianness only matters for layout of data in memory. As soon as data is loaded by the processor to be operated on, endianness is completely irrelevent. Shifts, bitwise operations, and so on perform as you would expect (data logically laid out as low-order bit to high) regardless of endianness.

Michael
  • 54,279
  • 5
  • 125
  • 144
  • 25
    Shouldn't it be "high to low order bit" logically? – legends2k Sep 08 '12 at 21:37
  • 1
    @legends2k: had same thought – Giorgi Moniava Mar 02 '15 at 12:53
  • 1
    @legends2k: yes. Left shift = multiply by power of 2. Right shift = divide by power of 2 (with different rounding than integer division for negative values). – Peter Cordes Aug 04 '15 at 20:40
  • Ok so does that mean hardware like the PDP-10 would convert the data to little-endian format to work on it? This goes against everything I've read so far; where this hardware performs byte operations in big endian and << performs a shift to the left. – Josh C Dec 01 '15 at 15:31
  • 2
    @JoshC: No, the PDP-10 would just perform the operation as it's logically defined on the data, regardless of exactly which bit is laid out where in its memory/registers. Consider: when you add two 32-bit integers, you don't worry about the processor having to convert the data in order for the addition to work (nor do you worry about the order of bits in a byte in the hardware) - the ALU just does the "right thing", because it's wired in a way that works with its hardware. The shifts are the same way - they operate on the data in a way that abstracts out the hardware's byte/bit order details. – mtraceur Apr 16 '16 at 17:38
  • 1
    @JoshC: (cont.) And in C, the bit shift operators are defined in a way that abstracts them even more: they are defined in terms of the values they produce, not in terms of the way they move the underlying bits around (so if you're on some obscure platform where a hardware bit-shift instruction would produce an invalid bit layout, e.g. you've shifted a value bit into a padding bit, a conforming compiler is required to produce instructions which work around that, as I understand it). – mtraceur Apr 16 '16 at 17:41
  • @JoshC: I'll be honest, I don't understand this comment. At first I thought you saw another one of my comments on another question, and meant to respond to that. Thinking about it further, however, I just can't be confident in any interpretation of that statement, given my above two comments. – mtraceur Apr 17 '16 at 02:59
71

The bitwise operators abstract away the endianness. For example, the >> operator always shifts the bits towards the least significant digit. However, this doesn't mean you are safe to completely ignore endianness when using them, for example when dealing with individual bytes in a larger structure you cannot always assume that they will fall in the same place.

short temp = 0x1234;
temp = temp >> 8;

// on little endian, c will be 0x12, on big endian, it will be 0x0
char c=((char*)&temp)[0];

To clarify, I am not in basic disagreement with the other answers here. The point I am trying to make is to emphasise that although the bitwise operators are essentially endian neutral, you cannot ignore the effect of endianess in your code, especially when combined with other operators.

legends2k
  • 31,634
  • 25
  • 118
  • 222
1800 INFORMATION
  • 131,367
  • 29
  • 160
  • 239
  • 1
    You are basically disagreeing with everyone but yet your answer was voted the best. How can identify the behaviors? – Frank V Jun 25 '09 at 00:33
  • I have added some further clarification – 1800 INFORMATION Jun 25 '09 at 00:57
  • 2
    So to further clarify you mean if unless I am actually retrieving values in bytes it all fine? – Suvarna Pattayil Feb 11 '15 at 14:31
  • 1
    O.o so >> and << aren't right or left shift at all; they're "shift towards least significant, and shift towards most significant". that makes "division and multiplication by shifting" endianness independant... now im confused if casting via memcpy would mess this up. – Dmytro Oct 21 '17 at 23:22
6

As others have mentioned, shifts are defined by the C language specification and are independent of endianness, but the implementation of a right shift may vary depending on iff the architecture uses one's complement or two's complement arithmetic.

rpetrich
  • 32,196
  • 6
  • 66
  • 89
4

It depends. Without casting the number into a new type, you can treat the endianness transparently.

However, if your operation involves some new type casting, then use your caution.

For example, if you want right shift some bits and cast (explicitly or not) to a new type, endianness matters!

To test your endianness, you can simply cast an int into a char:

int i = 1;

char *ptr;

...

ptr = (char *) &i;  //Cast it here

return  (*ptr);
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Rongkai Xu
  • 67
  • 1
  • ... Or create a union... `{union { int i = 1; char a[4];} b;return b.a[3] == 1;} //big endian` –  Jan 08 '15 at 23:55
3

You haven't specified a language but usually, programming languages such as C abstract endianness away in bitwise operations. So no, it doesn't matter in bitwise operations.

Mehrdad Afshari
  • 414,610
  • 91
  • 852
  • 789
  • 2
    Given that the question has no revisions, I'm surprised you say he hasn't mentioned language, when he does, and it's also tagged as C. – Simeon Pilgrim Jun 25 '09 at 02:27
  • 2
    @Simeon: It didn't have at the time I wrote this answer. Edits by a single author in a small time frame will be merged into one. That's why you're seeing it as a single revision. – Mehrdad Afshari Jun 25 '09 at 02:52