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]

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.

 

[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.

 

[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.

 

[Andrey Tarasevich]

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.

 

[Guest]

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]

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]

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]

(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]

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

 

[David T. Ashley]

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?

There is no such thing as "different order" of bits in a byte. Bits are
defined by the way they are used in numerical operations (i.e. when adding,
two 1's for B3 propagate the carry to B4).

The digital logic designers are free to design the digital logic any way
they'd like. Only the net connectivity matters.

Does any typical user know if maybe on the data bus inside the processor,
the bits might be arranged B0 B3 B6 B1, etc.?

 

[Keith Thompson]

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

[...]

Well, sort of. The language does require all object representations
to be made of "bytes", where each byte is made of CHAR_BIT "bits", and
the descriptions of the bitwise operators refer specifically to bits,
not to values. For example, the description of the bitwise AND
operator (C99 6.5.10) is:

The result of the binary & operator is the bitwise AND of the
operands (that is, each bit in the result is set if and only if
each of the corresponding bits in the converted operands is set).

Having said that, C could be implemented on a trinary machine, as long
as the implementation follows the rules; it would pretty much have to
emulate a binary machine.

 

[Walter Roberson]

There is no such thing as "different order" of bits in a byte. Bits are
defined by the way they are used in numerical operations (i.e. when adding,
two 1's for B3 propagate the carry to B4).

On the other hand, "bytes" are *not* defined by any numeric operation,
so a processor can order the bits within a byte in any way it wants,
as long as it is consistant enough that the required numerical
properties follow.

In this connection, it might interest you to know that in the
physical layers of ethernet at 10 megabits per second and below,
that the bits within an octet are transmitted LSB (least signficant bit)
first. That's why ethernet broadcast MAC addresses are those whose
first octet is odd in value -- because when that odd-valued octet
is transmitted LSB first, the odd-or-not bit (the LSB bit) is
the very first one onto the wire [after the preamble], so you
only have to look at the first header bit to determine broadcast or not.
Transmitting LSB first does not change the numeric properties associated
with the octet, just the external representation.

 

[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... )

The data is coming in byte-by-byte from an external device via
a serial port, so the most likely explanation is corrupted data
or flaky hardware. The one place which might have made a difference
is my interpretation of bit-shifts in unsigned character variables,
however it's been confirmed by others here that it's not the
problem.

Thanks for your comments.

Regards,
Charles Sullivan

 

[quarkLore]

In this case no you dont have to bother

Yes, that's always true. The shift operators in C are defined in
terms of numeric values, not how those values are represented.
--

No this is wrong. Shift operator depend on signed and unsigned
datatypes.
Right shift on a signed datatype will result in different bit value
(it will copy the
most significant bit in the empty places e.g. 11110000 when shifted by
one will give
11111000 if the variable was signed and 01111000 if unsigned)

There are other bitwise operations like masking operations which you
might have to look back again if you move to 64 bit platforms

 

[Dik T. Winter]

> Right shift on a signed datatype will result in different bit value
> (it will copy the
> most significant bit in the empty places e.g. 11110000 when shifted by
> one will give
> 11111000 if the variable was signed and 01111000 if unsigned)

Not necessarily. The standard does not define what happens with a right
shift on negative numbers. (I think it is stated as implementation defined.)
And I have used one machine that used a logical shift on signed integers,
simply because the processor did not *have* an arithmetic shift instruction.

 

[CBFalconer]

Not necessarily. The standard does not define what happens with
a right shift on negative numbers. (I think it is stated as
implementation defined.) And I have used one machine that used a
logical shift on signed integers, simply because the processor
did not *have* an arithmetic shift instruction.

On the DS9000 n = n >> M gives 1 for any M and negative n.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Andrey Tarasevich]

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

[...]

Well, sort of. The language does require all object representations
to be made of "bytes", where each byte is made of CHAR_BIT "bits",

Yes, but it doesn't require anywhere that these "bits" are in any way related to
the physical representation of data in the actual hardware. The above
requirement describes the C language object model. It is just a _model_ after all.

and
the descriptions of the bitwise operators refer specifically to bits,
not to values.

The same thing applies here. These "bits" are nothing more than individual
positions in the [imaginary] binary representation of the value.

Having said that, C could be implemented on a trinary machine, as long
as the implementation follows the rules; it would pretty much have to
emulate a binary machine.

Yes, but the "emulate part" comes into play only with such bit-specific
operations as bitwise logical and shifts. Maybe something else. Considering how
useful these operations are, it is quite possible that a practical ternary
machine will provide ready-to-use instructions that do all this already.

 

[Kenneth Lantrip]

Not necessarily. The standard does not define what happens with a right
shift on negative numbers. (I think it is stated as implementation defined.)
And I have used one machine that used a logical shift on signed integers,
simply because the processor did not *have* an arithmetic shift instruction.

Then why did the compiler not make a working code for such a missing
instruction? Isn't that a fault of the compiler?

if (x < 0) x == (1 << (sizeof(int) - 1)) || x >> 1; else x >>= 1;

or something like that?

 

[Guest]

Then why did the compiler not make a working code for such a missing
instruction? Isn't that a fault of the compiler?

It did generate working code. The generated code just didn't live up
to your expectations. When your expectations go beyond what the
standard requires and beyond what is reasonable for that platform,
that's not a fault of the compiler.