Bit shifting versus architecture question.

[Charles Sullivan]

I understand different processor hardware may store the bits in a
byte in different order. Does it make a difference in C insofar
as bit-shifting unsigned char variables is concerned?

E.g, if I have
unsigned char x = 1;
is it always true that
(x << 1) == 2
(x << 2) == 4
etc?

Or might I have to reverse the direction of the shift on some
architectures?

(I'm grasping at straws trying to figure out why some C software
written on my i86 system is failing when compiled on another
individual's PPC system.)

Thanks for your help.

Regards,
Charles Sullivan

[Ben Pfaff]

Charles Sullivan <cw******@triad .rr.comwrites:

E.g, if I have
unsigned char x = 1;
is it always true that
(x << 1) == 2
(x << 2) == 4
etc?

Yes, that's always true. The shift operators in C are defined in
terms of numeric values, not how those values are represented.
--
"This is a wonderful answer.
It's off-topic, it's incorrect, and it doesn't answer the question."
--Richard Heathfield

[Eric Sosman]

Charles Sullivan wrote On 02/07/07 14:46,:

I understand different processor hardware may store the bits in a
byte in different order. Does it make a difference in C insofar
as bit-shifting unsigned char variables is concerned?

E.g, if I have
unsigned char x = 1;
is it always true that
(x << 1) == 2
(x << 2) == 4
etc?

Yes.

Or might I have to reverse the direction of the shift on some
architectures?

No. "Order" only comes into play when you assemble two
or more smaller pieces into one larger piece, or decompose
the larger piece into smaller fragments. The shift operators,
like most C operators, works with the value that all the
pieces represent, no matter how it is represented. Thus,
even this:

int x = 128;
assert (x << 1 == 256);
assert (x << 2 == 512);

works identically on all systems, both Big- and LittleEndian,
even though the lone one-bit moves (probably) from one byte
of x to another.

(I'm grasping at straws trying to figure out why some C software
written on my i86 system is failing when compiled on another
individual's PPC system.)

I don't see how the paraphrase you've shown could be
responsible. If it's paraphrased from something a little
larger and you can post an actual snip of the larger thing,
maybe somebody will spot something helpful.

--
Er*********@sun .com

[Andrey Tarasevich]

Charles Sullivan wrote:

I understand different processor hardware may store the bits in a
byte in different order. Does it make a difference in C insofar
as bit-shifting unsigned char variables is concerned?

No. The hardware is not even required to have any "bits". There's nothing that
precludes a C implementation on, say, a ternary computer.

E.g, if I have
unsigned char x = 1;
is it always true that
(x << 1) == 2
(x << 2) == 4
etc?

Yes. The notion of "bit" in C refers to an element of the traditional binary
notation, not to the hardware bit. '1' is always '1' in binary , while '2' is
always '10' in binary. This means that a single left shift will always turn 1
into 2.

Or might I have to reverse the direction of the shift on some
architectures?

No.

--
Best regards,
Andrey Tarasevich

[Flash Gordon]

Charles Sullivan wrote, On 07/02/07 19:46:

I understand different processor hardware may store the bits in a
byte in different order. Does it make a difference in C insofar
as bit-shifting unsigned char variables is concerned?

E.g, if I have
unsigned char x = 1;
is it always true that
(x << 1) == 2
(x << 2) == 4
etc?

Or might I have to reverse the direction of the shift on some
architectures?

On unsigned types shifting always behaves the same. The result of right
shifting a negative number is implementation defined.

(I'm grasping at straws trying to figure out why some C software
written on my i86 system is failing when compiled on another
individual's PPC system.)

Start by turning up the warnings on your compiler, understanding
everything it complains about, and fixing it (don't cast just to remove
a warning).

If your program is in standard C (modulo errors) then cut it down to a
sensible size that shows a difference and post it here and we can help.
--
Flash Gordon

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Charles Sullivan wrote:

I understand different processor hardware may store the bits in a
byte in different order. Does it make a difference in C insofar
as bit-shifting unsigned char variables is concerned?

No, bit shifting by N bits is defined as a multiplication or division
by 2**N.

E.g, if I have
unsigned char x = 1;
is it always true that
(x << 1) == 2
(x << 2) == 4
etc?

Yes, that is always true.

Or might I have to reverse the direction of the shift on some
architectures?

(I'm grasping at straws trying to figure out why some C software
written on my i86 system is failing when compiled on another
individual's PPC system.)

If you could shorten the code to a minimal example that displays your
problem, you might get the answer here.

[Charles Sullivan]

On Wed, 07 Feb 2007 14:46:03 -0500, I wrote:

I understand different processor hardware may store the bits in a
byte in different order. Does it make a difference in C insofar
as bit-shifting unsigned char variables is concerned?

<remainder snipped>

Thanks guys - Ben, Harald, Andrey, Flash, and Eric.
I just wanted to make sure I wasn't doing something obviously
stupid.

The system involves reading and writing to an external device
which may or may not be cranky connected via a USB->Serial
adapter which may or may not be well-supported by its OS's driver.

At this point I'm pretty sure it's not a C language problem.

I appreciate the time you've all taken to answer my question.

Regards,
Charles Sullivan

[forkazoo]

On Feb 7, 12:46 pm, Charles Sullivan <cwsul...@triad .rr.comwrote:

I understand different processor hardware may store the bits in a
byte in different order. Does it make a difference in C insofar
as bit-shifting unsigned char variables is concerned?

E.g, if I have
unsigned char x = 1;
is it always true that
(x << 1) == 2
(x << 2) == 4
etc?

Or might I have to reverse the direction of the shift on some
architectures?

(I'm grasping at straws trying to figure out why some C software
written on my i86 system is failing when compiled on another
individual's PPC system.)

Thanks for your help.

Regards,
Charles Sullivan

Are you dealing with any data coming from files or from a network
connection? This is one of the easiest places to get in trouble while
making non-portable assumptions. (The particulars of doing network
stuff are obviously off topic here, but I think it's still on topic to
point out that reading raw data from foreign sources can get you in
trouble.)

Also, bits aren't the only concern. Bytes can be arranged "funny" in
larger types on architectures that aren't your favorite. Lucky for
you, your x86 implimentation and your PPC implimentation probably both
use 8 bit bytes and chars. :)

If the trouble isn't from corrupt external data, then I'd expect that
you may have made a non-portable assumption about types being the
same. A pointer to an int can't portably be treated as a pointer to a
short or a long, etc. If you don't specify if you want a signed or
unsigned char, the implimentation isn't obliged to give you one or the
other.

Off the top of my head, those are the things that I tend to screw up
when I've moved things from x86 to PPC. (All the while, muttering
that I had done everything perfectly, and it must be a compiler
bug... :) )

[Christopher Layne]

Charles Sullivan wrote:

(I'm grasping at straws trying to figure out why some C software
written on my i86 system is failing when compiled on another
individual's PPC system.)

Thanks for your help.

Regards,
Charles Sullivan

Sounds like an endian issue (byte-order) rather than a bit-order issue.

[Charles Sullivan]

On Wed, 07 Feb 2007 17:11:09 -0800, Christopher Layne wrote:

Charles Sullivan wrote:

>(I'm grasping at straws trying to figure out why some C software
written on my i86 system is failing when compiled on another
individual's PPC system.)

Thanks for your help.

Regards,
Charles Sullivan

Sounds like an endian issue (byte-order) rather than a bit-order issue.

Thanks for your comment and taking the time to respond.
At the stage where the problem exists the data is being
handled strictly on a byte-by-byte basis, so byte order
shouldn't enter into it.

Regards,
Charles Sullivan