reversing a byte

[Ajay]

Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.

[Richard Heathfield]

jaysome said:

[...] I highly suspect that the OP will ever use an implementation
that defines "CHAR_BIT > 8".
If he sticks with C, it's almost inevitable in the long run.

Nor would I suspect that most other C programmers will.

Well, I certainly have used such an implementation, and so have a whole
bunch of people I was working with at the time, and so has anyone else who
has written C for the same chip, and so have lots of other people writing C
for other similar chips, too. And such chips, common a few years ago, are
becoming yet more common all the time.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[jaysome]

Richard Heathfield wrote:

jaysome said:

[...] I highly suspect that the OP will ever use an implementation
that defines "CHAR_BIT > 8".

If he sticks with C, it's almost inevitable in the long run.

Nor would I suspect that most other C programmers will.

Well, I certainly have used such an implementation, and so have a whole
bunch of people I was working with at the time, and so has anyone else who
has written C for the same chip, and so have lots of other people writing C
for other similar chips, too. And such chips, common a few years ago, are
becoming yet more common all the time.

Okay.

But the fact that you and your co-workers and probably some of your
friends and their friends have used such an implementation does not
hardly qualify for "most" C programmers. After all, you are a revered
mavin here in c.l.c., and you most likely attract others of your type :)

To be sure--a table impementation is fine as long as you understand the
ramifications to portability. And I reiterate--most C programmers will
be just fine, whether of not they understand the ramifications.

--
jay

[Vladimir S. Oka]

jaysome wrote:

Richard Heathfield wrote:

jaysome said:

[...] I highly suspect that the OP will ever use an implementation
that defines "CHAR_BIT > 8".

If he sticks with C, it's almost inevitable in the long run.

Nor would I suspect that most other C programmers will.

Well, I certainly have used such an implementation, and so have a whole
bunch of people I was working with at the time, and so has anyone else who
has written C for the same chip, and so have lots of other people writing C
for other similar chips, too. And such chips, common a few years ago, are
becoming yet more common all the time.

Okay.

But the fact that you and your co-workers and probably some of your
friends and their friends have used such an implementation does not
hardly qualify for "most" C programmers. After all, you are a revered
mavin here in c.l.c., and you most likely attract others of your type :)

To be sure--a table impementation is fine as long as you understand the
ramifications to portability.

That's fair enough.
And I reiterate--most C programmers will
be just fine, whether of not they understand the ramifications.

Can I borrow your crystal ball, please. I'm going to the races. ;-)

How can you be so sure that the next Big Thing in processors won't
have, say, 16 for CHAR_BIT? How long did it take from Intel 4004 to
80386? [non-ASCII native moan: After all, it's high time `char` really
becoming able to represent characters from more than a handful of
languages, without making us jump through hoops.]

Also, it's not necessarilly /today's/ programmers, rather the ones that
will maintain their code, or try to port it to future architectures.

--
BR, Vladimir

--
BR, Vladimir

[jaysome]

Vladimir S. Oka wrote:

jaysome wrote:

Richard Heathfield wrote:

jaysome said:

[...] I highly suspect that the OP will ever use an implementation
that defines "CHAR_BIT > 8".
If he sticks with C, it's almost inevitable in the long run.


Nor would I suspect that most other C programmers will.
Well, I certainly have used such an implementation, and so have a whole
bunch of people I was working with at the time, and so has anyone else who
has written C for the same chip, and so have lots of other people writing C
for other similar chips, too. And such chips, common a few years ago, are
becoming yet more common all the time.

Okay.

But the fact that you and your co-workers and probably some of your
friends and their friends have used such an implementation does not
hardly qualify for "most" C programmers. After all, you are a revered
mavin here in c.l.c., and you most likely attract others of your type :)

To be sure--a table impementation is fine as long as you understand the
ramificatio ns to portability.

That's fair enough.

And I reiterate--most C programmers will
be just fine, whether of not they understand the ramifications.

Can I borrow your crystal ball, please. I'm going to the races. ;-)

How can you be so sure that the next Big Thing in processors won't
have, say, 16 for CHAR_BIT?

When, and if, that happens, Microsoft, or some Open Source developers,
will put out an announcement stating that your existing C programs may
be in jeapordy if you have, in arguably a pedantic manner, assumed that
"CHAR_BIT == 8".

(I just searched all 448 source files of one project I work on. Only one
references CHAR_BIT (yippee for me!). I wouldn't be surprised if many of
the regulars here would search their source code and find 0 instances of
use of CHAR_BIT. And I would be eager to hear about how such lack of
usage of CHAR_BIT affects portability.)

My guess--kind of reiterated--is that those who know better will get it
right, and those that don't know better will, well, be just fine.

--
jay

[Vladimir S. Oka]

jaysome wrote:

Vladimir S. Oka wrote:

jaysome wrote:

Richard Heathfield wrote:
jaysome said:

>[...] I highly suspect that the OP will ever use an implementation
>that defines "CHAR_BIT > 8".

If he sticks with C, it's almost inevitable in the long run.

>Nor would I suspect that most other C programmers will.

Well, I certainly have used such an implementation, and so have a whole
bunch of people I was working with at the time,
<snip>

Okay.

But the fact that you and your co-workers and probably some of your
friends and their friends have used such an implementation does not
hardly qualify for "most" C programmers. After all, you are a revered
mavin here in c.l.c., and you most likely attract others of your type :)

To be sure--a table impementation is fine as long as you understand the
ramificatio ns to portability.
That's fair enough.

And I reiterate--most C programmers will
be just fine, whether of not they understand the ramifications.

Can I borrow your crystal ball, please. I'm going to the races. ;-)

How can you be so sure that the next Big Thing in processors won't
have, say, 16 for CHAR_BIT?

When, and if, that happens, Microsoft, or some Open Source developers,
will put out an announcement stating that your existing C programs may
be in jeapordy if you have, in arguably a pedantic manner, assumed that
"CHAR_BIT == 8".

You mean like for Y2K problem: s*itloads of money and time will be
spent fixing the avoidable mess?
(I just searched all 448 source files of one project I work on. Only one
references CHAR_BIT (yippee for me!).
Relevant only if your code /relies/ on CHAR_BIT size.
I wouldn't be surprised if many of
the regulars here would search their source code and find 0 instances of
use of CHAR_BIT.
I'd really like that crystal ball of yours...
And I would be eager to hear about how such lack of
usage of CHAR_BIT affects portability.)
Say your code relies on the fact that CHAR_BIT is 8 (or any other
value), and you use a table of 256 values for reversing a `char`
(sounds familiar?). Now, try to re-compile for the architecture with
CHAR_BIT being 9. See the point? I guess even your neat utility that
generates the said table relies on CHAR_BIT being 8, so re-compiling,
and re-running that doesn't help either. Now, where in all those 448
(or 1448, or 11448) source files was that pesky table?!
My guess--kind of reiterated--is that those who know better will get it
right, and those that don't know better will, well, be just fine.

They may be "just fine", I'm worried about someone (possibly me) having
to maintain and port their code, not to mention the possibility of
Ariane, Therac-25 and similar.

--
BR, Vladimir

[santosh]

jaysome wrote:

Vladimir S. Oka wrote:

How can you be so sure that the next Big Thing in processors won't
have, say, 16 for CHAR_BIT?

When, and if, that happens, Microsoft, or some Open Source developers,
will put out an announcement stating that your existing C programs may
be in jeapordy if you have, in arguably a pedantic manner, assumed that
"CHAR_BIT == 8".

(I just searched all 448 source files of one project I work on. Only one
references CHAR_BIT (yippee for me!). I wouldn't be surprised if many of
the regulars here would search their source code and find 0 instances of
use of CHAR_BIT. And I would be eager to hear about how such lack of
usage of CHAR_BIT affects portability.)

My guess--kind of reiterated--is that those who know better will get it
right, and those that don't know better will, well, be just fine.

Nevertheless, all other factor being equal, if there's a fully portable
way to do something, then that is to be preferred over making
assumptions and hard-coding values. That's the point CBFalconer was
making to Charles Mills.

[osmium]

"CBFalconer " wrote:

<snip table driven solution>

Works like a charm, NOT, when CHAR_BIT > 8. i.e. document hidden
assumptions.

Can we back up here?

The OP wanted to get a job, right? He was asked a stupid question, since
there are at least three ways to measure efficiency - footprint, speed,
programmer's time and clarity etc. The OP has two choices, he can say "WTF
do you mean" or he can give the answer this doofus actually wants, a table
look up. Is there even the tiniest doubt that that was the desired answer
to successfully continue the interview? Do you really think this guy
(hopefully from "Human Resources") cares or even knows about peculiar
representations of characters?

[Vladimir S. Oka]

osmium wrote:

"CBFalconer " wrote:

<snip table driven solution>

Works like a charm, NOT, when CHAR_BIT > 8. i.e. document hidden
assumptions.

Can we back up here?

The OP wanted to get a job, right? He was asked a stupid question, since
there are at least three ways to measure efficiency - footprint, speed,
programmer's time and clarity etc. The OP has two choices, he can say "WTF
do you mean" or he can give the answer this doofus actually wants, a table
look up. Is there even the tiniest doubt that that was the desired answer
to successfully continue the interview? Do you really think this guy
(hopefully from "Human Resources") cares or even knows about peculiar
representations of characters?

If I was interviewed on C skills by an HR drone, I'd say "thank you"
and leave there and then. If I thought the engineer interviewing me
didn't "care or even know" about such things, I'd run as fast as I
could. If neither was the case, I'd expect to be grilled on just such
an point.

--
BR, Vladimir

[pete]

Ajay wrote:

Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.

unsigned char bit_rev(unsigne d char byte)
{
unsigned hi_mask, lo_mask;

hi_mask = ((unsigned char)-1 >> 1) + 1;
lo_mask = 1;
do {
if (!(byte & hi_mask) != !(byte & lo_mask)) {
byte ^= hi_mask | lo_mask;
}
hi_mask >>= 1;
lo_mask <<= 1;
} while (hi_mask > lo_mask);
return byte;
}

--
pete

[santosh]

pete wrote:

Ajay wrote:

Hi all,can you please tell the most efficient method to reverse a
byte.Function should return a byte that is reversed.
unsigned char bit_rev(unsigne d char byte)
{
unsigned hi_mask, lo_mask;

hi_mask = ((unsigned char)-1 >> 1) + 1;

This is probably a stupid question, but why not simply do hi_mask =
128;?
lo_mask = 1;
do {
if (!(byte & hi_mask) != !(byte & lo_mask)) {
byte ^= hi_mask | lo_mask;
}
hi_mask >>= 1;
lo_mask <<= 1;
} while (hi_mask > lo_mask);
return byte;
}

wow, that took me quite a while to figure out! Just out of curiosity,
is this the "most efficient" method to reverse bits that you know of?