448,712 Members | 1,591 Online
Need help? Post your question and get tips & solutions from a community of 448,712 IT Pros & Developers. It's quick & easy.

# reversing a byte

 P: n/a Hi all,can you please tell the most efficient method to reverse a byte.Function should return a byte that is reversed. Mar 22 '06 #1
45 Replies

 P: n/a "Ajay" writes: Hi all,can you please tell the most efficient method to reverse a byte.Function should return a byte that is reversed. By writing a function to do it. C would be a good choice of language for this task. Good luck. If you want somebody else to do it for you, I'm sure you can find someone willing to discuss consulting rates. If this is homework, please give us your instructor's e-mail address so we can submit our solutions directly. And in anticipation of your next followup, please read . -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Mar 22 '06 #2

 P: n/a Ajay wrote: Hi all,can you please tell the most efficient method to reverse a byte.Function should return a byte that is reversed. Use a look up table (untested generated code below): static unsigned char reverse_byte(unsigned char b) { static const unsigned char b_tbl[] = { 0xff, 0xfe, 0xfd, 0xfc, 0xfb, 0xfa, 0xf9, 0xf8, 0xf7, 0xf6, 0xf5, 0xf4, 0xf3, 0xf2, 0xf1, 0xf0, 0xef, 0xee, 0xed, 0xec, 0xeb, 0xea, 0xe9, 0xe8, 0xe7, 0xe6, 0xe5, 0xe4, 0xe3, 0xe2, 0xe1, 0xe0, 0xdf, 0xde, 0xdd, 0xdc, 0xdb, 0xda, 0xd9, 0xd8, 0xd7, 0xd6, 0xd5, 0xd4, 0xd3, 0xd2, 0xd1, 0xd0, 0xcf, 0xce, 0xcd, 0xcc, 0xcb, 0xca, 0xc9, 0xc8, 0xc7, 0xc6, 0xc5, 0xc4, 0xc3, 0xc2, 0xc1, 0xc0, 0xbf, 0xbe, 0xbd, 0xbc, 0xbb, 0xba, 0xb9, 0xb8, 0xb7, 0xb6, 0xb5, 0xb4, 0xb3, 0xb2, 0xb1, 0xb0, 0xaf, 0xae, 0xad, 0xac, 0xab, 0xaa, 0xa9, 0xa8, 0xa7, 0xa6, 0xa5, 0xa4, 0xa3, 0xa2, 0xa1, 0xa0, 0x9f, 0x9e, 0x9d, 0x9c, 0x9b, 0x9a, 0x99, 0x98, 0x97, 0x96, 0x95, 0x94, 0x93, 0x92, 0x91, 0x90, 0x8f, 0x8e, 0x8d, 0x8c, 0x8b, 0x8a, 0x89, 0x88, 0x87, 0x86, 0x85, 0x84, 0x83, 0x82, 0x81, 0x80, 0x7f, 0x7e, 0x7d, 0x7c, 0x7b, 0x7a, 0x79, 0x78, 0x77, 0x76, 0x75, 0x74, 0x73, 0x72, 0x71, 0x70, 0x6f, 0x6e, 0x6d, 0x6c, 0x6b, 0x6a, 0x69, 0x68, 0x67, 0x66, 0x65, 0x64, 0x63, 0x62, 0x61, 0x60, 0x5f, 0x5e, 0x5d, 0x5c, 0x5b, 0x5a, 0x59, 0x58, 0x57, 0x56, 0x55, 0x54, 0x53, 0x52, 0x51, 0x50, 0x4f, 0x4e, 0x4d, 0x4c, 0x4b, 0x4a, 0x49, 0x48, 0x47, 0x46, 0x45, 0x44, 0x43, 0x42, 0x41, 0x40, 0x3f, 0x3e, 0x3d, 0x3c, 0x3b, 0x3a, 0x39, 0x38, 0x37, 0x36, 0x35, 0x34, 0x33, 0x32, 0x31, 0x30, 0x2f, 0x2e, 0x2d, 0x2c, 0x2b, 0x2a, 0x29, 0x28, 0x27, 0x26, 0x25, 0x24, 0x23, 0x22, 0x21, 0x20, 0x1f, 0x1e, 0x1d, 0x1c, 0x1b, 0x1a, 0x19, 0x18, 0x17, 0x16, 0x15, 0x14, 0x13, 0x12, 0x11, 0x10, 0xf, 0xe, 0xd, 0xc, 0xb, 0xa, 0x9, 0x8, 0x7, 0x6, 0x5, 0x4, 0x3, 0x2, 0x1, 0x0 }; return b_tbl[b]; } -Charlie Mar 22 '06 #3

 P: n/a Charles Mills 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. Use a look up table (untested generated code below): static unsigned char reverse_byte(unsigned char b) { static const unsigned char b_tbl[] = { ---8<---- sniped totally wrong lookup table ---8<---- }; return b_tbl[b]; } -Charlie probably want something like this: static const unsigned char b_tbl[] = { 0x0, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0, 0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0, ..., 0xf, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef, 0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff }; you can fill in the blanks. -Charlie Mar 22 '06 #4

 P: n/a Charles Mills 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. Use a look up table (untested generated code below): static unsigned char reverse_byte(unsigned char b) { static const unsigned char b_tbl[] = { ---8<---- sniped totally wrong lookup table ---8<---- }; return b_tbl[b]; } -Charlie probably want something like this: static const unsigned char b_tbl[] = { 0x0, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0, 0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0, ..., 0xf, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef, 0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff }; you can fill in the blanks. -Charlie Mar 22 '06 #5

 P: n/a Hi I give here a piece of code to reverse a byte but iam not sure how good it is... unsigned int n=0x01; unsinged int c=0x00; int i; /* b is given byte */ for( i=0; i<8 ;i++) { if( b & n) { c=c + 1;} c<<1; n<<1; } /* the reversed value is stored in c */ -------------------- any one please correct this if any wrong. Ajay wrote: Hi all,can you please tell the most efficient method to reverse a byte.Function should return a byte that is reversed. Mar 22 '06 #6

 P: n/a sudharsan wrote: Don't top-post. I've corrected it here... Ajay wrote: Hi all,can you please tell the most efficient method to reverse a byte.Function should return a byte that is reversed. Hi I give here a piece of code to reverse a byte but iam not sure how good it is... Why bother posting untested and uncompilable code in response to someone's question? #include #include int main(void) { unsigned int n=0x01; unsinged int c=0x00; You surely mean: unsigned int c = 0x00; unsigned int b = 15; int i; /* b is given byte */ for( i=0; i<8 ;i++) { if( b & n) { c=c + 1;} You never declare `b`, let alone assign it value. c<<1; n<<1; These two do precisely nothing (useful); } /* the reversed value is stored in c */ printf("b = %d, c = %d\n", b, c); return 0; } So the result is "b = 15, c = 8", `c` being 8 for any `b`. any one please correct this if any wrong. I've corrected above it so it will compile and run. Now it's your turn to correct the logic. You did have an idea how to do this, didn't you? -- BR, Vladimir Mar 22 '06 #7

 P: n/a Ajay wrote: Hi all,can you please tell the most efficient method to reverse a byte.Function should return a byte that is reversed. Your question is not very clear. Do you need to reverse the *value* of the bits in a byte or do you need to reverse their *position*? If you need to do the former, you can use C's complement operator, (~). If the latter, you'll need to write a function to do it. If you want it to be very fast, probably using a 256 byte look-up table is the way to go. Mar 22 '06 #8

 P: n/a Charles Mills wrote: Charles Mills 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. Use a look up table (untested generated code below): static unsigned char reverse_byte(unsigned char b) { static const unsigned char b_tbl[] = { ---8<---- sniped totally wrong lookup table ---8<---- }; return b_tbl[b]; } probably want something like this: static const unsigned char b_tbl[] = { 0x0, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0, 0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0, ..., 0xf, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef, 0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff }; you can fill in the blanks. Works like a charm, NOT, when CHAR_BIT > 8. i.e. document hidden assumptions. In order of execution: unsigned char* b_tbl = malloc(1 + UCHAR_MAX); ... /* code to initialize table, after checking it is non-NULL. */ ... /* code that uses the table */ -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: Also see Mar 22 '06 #9

 P: n/a sudharsan wrote: I give here a piece of code to reverse a byte but iam not sure how good it is... Well, I'm not commenting on how good it is ... but a) it's not portable. b) you could have posted the full function definition along with the comments about `b` and `c`. c) it's very poorly indented. d) your use of whitespace is very strange. #include /* for CHAR_BIT */ unsigned int reverse_byte(unsigned int b) { unsigned int n=0x01; unsinged int c=0x00; int i; /* b is given byte */ #if 0 for( i=0; i<8 ;i++) #endif /* Why do you assume a byte is 8 bits? */ for( i=0; i Mar 22 '06 #10

 P: n/a Hi Eric,Firsto of all thanks for the solution.I understand here what you want to say but i think in any language(specially in C language)implementation of algorithm is the most importent thing.this is not about a simple question like this.But the habbit to think differently start from this point.All the big companies i have gone for ask only for efficient and fast solution(with respect to memory/speed).Anybody can make program..isn't it?bt it depend how you make it. I appreciate for your solution but i want to impement the program on my own.See if you can help me out--- Function prototype shuold be Byte * Reverse(byte) where byte for example:--- 11100010 output should be ---------- 01000111 Mar 22 '06 #12

 P: n/a Ajay wrote: Hi Eric,Firsto of all Quote context! Read: thanks for the solution.I understand here what you want to say but i think in any language(specially in C language)implementation of algorithm is the most importent thing.this is not about a simple question like this.But the habbit to think differently start from this point.All the big companies i have gone for ask only for efficient and fast solution(with respect to memory/speed).Anybody can make program..isn't it?bt it depend how you make it. The right approach is: 1. code it in a readable and correct fashion 2. *mesure* 3. if 2. is unsatisfactory, only then improve efficiency If you don't plan on doing 2., the rules of optimisation are: 1. Don't do it 2. (experts only) Don't do it yet. I appreciate for your solution but i want to impement the program on my own.See if you can help me out--- Function prototype shuold be Byte * Reverse(byte) where byte for example:--- 11100010 output should be ---------- 01000111 By writing it for you? Fat chance! -- BR, Vladimir Mar 22 '06 #13

 P: n/a Ajay, le 22/03/2006 a écrit : [...] Function prototype shuold be Byte * Reverse(byte) where byte for example:--- 11100010 output should be ---------- 01000111 several ways here: http://graphics.stanford.edu/~seande...ReverseObvious You can choose calculation methods for short code, lookup table method for fast code. You can use your own code for a calculation method generating the lookup table (text) and copy-paste in your final code. When you have Reverse(), you check Reverse(Reverse()) is identity. -- Pierre Maurette Mar 22 '06 #14

 P: n/a "Ajay" writes: Hi Eric,Firsto of all thanks for the solution.I understand here what you want to say but i think in any language(specially in C language)implementation of algorithm is the most importent thing.this is not about a simple question like this.But the habbit to think differently start from this point.All the big companies i have gone for ask only for efficient and fast solution(with respect to memory/speed).Anybody can make program..isn't it?bt it depend how you make it. I appreciate for your solution but i want to impement the program on my own.See if you can help me out--- Function prototype shuold be Byte * Reverse(byte) If you want to implement it on your own, what are you asking us for? (That's a serious question.) Your prototype: Byte *Reverse(byte) looks odd. There is no predefined type "Byte" or "byte" in C (those are two different identifiers), and I can't imagine why you'd want to return a pointer. You probably want unsigned char reverse(unsigned char *x); where byte for example:--- 11100010 output should be ---------- 01000111 And please read if you want anyone to know what you're talking about. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Mar 22 '06 #16

 P: n/a Keith Thompson writes: [...] Your prototype: Byte *Reverse(byte) looks odd. There is no predefined type "Byte" or "byte" in C (those are two different identifiers), and I can't imagine why you'd want to return a pointer. You probably want unsigned char reverse(unsigned char *x); Sorry, I *really* didn't want the '*' there. The prototype should be unsigned char reverse(unsigned char x); -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Mar 22 '06 #17

 P: n/a "Richard G. Riley" wrote: On 2006-03-22, Eric Sosman wrote: .... snip ... For future reference: The C language says nothing about the amount of time any operation requires, nothing about the amount of space any executable code occupies, nothing about the power consumption of the computer running the code, and very little about the amount of space taken by data objects. Most notions No, but it is a language picked for its brevity and efficiency : a fair programmer can almost see the instructions generated and frequently pick the language for just that feature. There is a reason that Java or Perl or somesuch is not used for writing 3d modelling engines expected to render 32 bit graphics in real time. For a minority, yes. It seems to me that the majority of programmers today wouldn't recognize a conditional jump, or an indirect reference, in assembly code if it jumped up and bit them on the gluteus maximus. -- "The power of the Executive to cast a man into prison without formulating any charge known to the law, and particularly to deny him the judgement of his peers, is in the highest degree odious and is the foundation of all totalitarian government whether Nazi or Communist." -- W. Churchill, Nov 21, 1943 Mar 23 '06 #18

 P: n/a Ajay wrote: Hi all,can you please tell the most efficient method to reverse a efficient here is compact code or compact logic not other stuffs.. byte.Function should return a byte that is reversed. Mar 23 '06 #19

 P: n/a CBFalconer wrote: Charles Mills wrote:Charles Mills wrote:Ajay wrote:Hi all,can you please tell the most efficient method to reversea byte.Function should return a byte that is reversed.Use a look up table (untested generated code below):static unsigned charreverse_byte(unsigned char b){ static const unsigned char b_tbl[] = {---8<---- sniped totally wrong lookup table ---8<---- }; return b_tbl[b];}probably want something like this: static const unsigned char b_tbl[] = { 0x0, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0, 0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0, ..., 0xf, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef, 0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff };you can fill in the blanks. Works like a charm, NOT, when CHAR_BIT > 8. i.e. document hidden assumptions. In order of execution: True, but I highly suspect that the OP will ever use an implementation that defines "CHAR_BIT > 8". Nor would I suspect that most other C programmers will. -- jay Mar 23 '06 #20

 P: n/a 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) Mar 23 '06 #21

 P: n/a Richard Heathfield wrote: jaysome said:[...] I highly suspect that the OP will ever use an implementationthat 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 Mar 23 '06 #22

 P: n/a jaysome wrote: Richard Heathfield wrote: jaysome said:[...] I highly suspect that the OP will ever use an implementationthat 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 Mar 23 '06 #23

 P: n/a Vladimir S. Oka wrote: jaysome wrote:Richard Heathfield wrote:jaysome said: [...] I highly suspect that the OP will ever use an implementationthat 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 wholebunch of people I was working with at the time, and so has anyone else whohas written C for the same chip, and so have lots of other people writing Cfor other similar chips, too. And such chips, common a few years ago, arebecoming yet more common all the time.Okay.But the fact that you and your co-workers and probably some of yourfriends and their friends have used such an implementation does nothardly qualify for "most" C programmers. After all, you are a reveredmavin 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 theramifications to portability. That's fair enough.And I reiterate--most C programmers willbe 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 Mar 23 '06 #24

 P: n/a 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. Mar 23 '06 #26

 P: n/a "CBFalconer" wrote: 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? Mar 23 '06 #27

 P: n/a osmium wrote: "CBFalconer" wrote: 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 Mar 23 '06 #28

 P: n/a -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 santosh wrote: 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(unsigned 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;? Because a char /may/ contain more than 8 bits. The statement hi_mask = ((unsigned char)-1 >> 1) + 1; will result in hi_mask having a char value that only has it's high order bit on, no matter what size (in bits) a char is. OTOH, hi_mask = 128; is only guaranteed to set /a/ bit (not necessarily the high order bit) to one. [snip] - -- Lew Pitcher, IT Specialist, Corporate Technology Solutions, Enterprise Technology Solutions, TD Bank Financial Group (Opinions expressed here are my own, not my employer's) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEIuJLagVFX4UWr64RAiPqAJ46Gyhsr/6x/nXtNBsc8BGiJmowcACg2EUF eKgfiLiLY8ze4DrsXA3pT5Q= =k/wz -----END PGP SIGNATURE----- Mar 23 '06 #31

 P: n/a CBFalconer wrote: Charles Mills wrote: Charles Mills 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. Use a look up table (untested generated code below): static unsigned char reverse_byte(unsigned char b) { static const unsigned char b_tbl[] = { ---8<---- sniped totally wrong lookup table ---8<---- }; return b_tbl[b]; } probably want something like this: static const unsigned char b_tbl[] = { 0x0, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0, 0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0, ..., 0xf, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef, 0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff }; you can fill in the blanks. Works like a charm, NOT, when CHAR_BIT > 8. i.e. document hidden assumptions. In order of execution: unsigned char* b_tbl = malloc(1 + UCHAR_MAX); ... /* code to initialize table, after checking it is non-NULL. */ ... /* code that uses the table */ Here is another non protable (but interesting) version based on code from the book Hackers Delight: #if CHAR_BIT != 8 # error ---> Code below only works on platforms with CHAR_BIT == 8 #endif static unsigned char reverse_byte(unsigned char x) { x = (x & 0x55) << 1 | (x >> 1) & 0x55; x = (x & 0x33) << 2 | (x >> 2) & 0x33; x = (x & 0x0F) << 4 | (x >> 4) & 0x0F; return x; } Nice divide and conquer approach 0x55 => 01010101 0x33 => 00110011 0x0F => 00001111 -Charlie Mar 23 '06 #32

 P: n/a Lew Pitcher wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 santosh wrote: 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(unsigned 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;? Because a char /may/ contain more than 8 bits. The statement hi_mask = ((unsigned char)-1 >> 1) + 1; will result in hi_mask having a char value that only has it's high order bit on, no matter what size (in bits) a char is. OTOH, hi_mask = 128; is only guaranteed to set /a/ bit (not necessarily the high order bit) to one. [snip] Thanks. Mar 23 '06 #33

 P: n/a 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(unsigned char byte) { unsigned hi_mask, lo_mask; hi_mask = ((unsigned char)-1 >> 1) + 1; [snip rest of function definition] Does this work for one's complement or any other representation of negative numbers besides two's complement? Maybe hi_mask = (UCHAR_MAX + 1) >> 1; is more portable? -- If you're posting through Google read Mar 23 '06 #35

 P: n/a santosh wrote: jaysome wrote: .... snip ... (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. Thank you. And, lacking that, document the assumption. E.G: assert(8 == CHAR_BIT); -- "The power of the Executive to cast a man into prison without formulating any charge known to the law, and particularly to deny him the judgement of his peers, is in the highest degree odious and is the foundation of all totalitarian government whether Nazi or Communist." -- W. Churchill, Nov 21, 1943 Mar 23 '06 #36

 P: n/a Pedro Graca wrote: 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(unsigned char byte) { unsigned hi_mask, lo_mask; hi_mask = ((unsigned char)-1 >> 1) + 1; [snip rest of function definition] Does this work for one's complement or any other representation of negative numbers besides two's complement? Yes. Maybe hi_mask = (UCHAR_MAX + 1) >> 1; is more portable? Not more portable, but slightly better style, perhaps. (UCHAR_MAX == (unsigned char)-1) is always true, regardless of the representation of negative integers. N869 6.3.1.3 Signed and unsigned integers [#1] When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged. [#2] Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type. ((unsigned char)-1 == -1 + UCHAR_MAX + 1) ((unsigned char)-1 == UCHAR_MAX ) -- pete Mar 23 '06 #37

 P: n/a pete wrote: Pedro Graca wrote: Maybe hi_mask = (UCHAR_MAX + 1) >> 1; is more portable? Not more portable, but slightly better style, perhaps. Actually, (UCHAR_MAX + 1) is not portable. If UCHAR_MAX is equal to UINT_MAX, then (hi_mask = (UCHAR_MAX + 1) >> 1) is equal to zero. -- pete Mar 23 '06 #38

 P: n/a pete wrote: Actually, (UCHAR_MAX + 1) is not portable. If UCHAR_MAX is equal to UINT_MAX, then (hi_mask = (UCHAR_MAX + 1) >> 1) is equal to zero. What about hi_mask = (UCHAR_MAX >> 1) + 1; -- If you're posting through Google read Mar 23 '06 #39

 P: n/a Pedro Graca wrote: pete wrote: Actually, (UCHAR_MAX + 1) is not portable. If UCHAR_MAX is equal to UINT_MAX, then (hi_mask = (UCHAR_MAX + 1) >> 1) is equal to zero. What about hi_mask = (UCHAR_MAX >> 1) + 1; That's what I thought you had written when I replied "Not more portable, but slightly better style, perhaps." -- pete Mar 23 '06 #40

 P: n/a pete wrote: pete wrote: Pedro Graca wrote: hi_mask = (UCHAR_MAX + 1) >> 1; is more portable? Not more portable, but slightly better style, perhaps. Actually, (UCHAR_MAX + 1) is not portable. If UCHAR_MAX is equal to UINT_MAX, then (hi_mask = (UCHAR_MAX + 1) >> 1) is equal to zero. and, if UCHAR_MAX is equal to INT_MAX, the expression creates undefined (or system defined) behaviour, due to the silly way that integer promotions work. Unsignedness is not preserved. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: Also see Mar 24 '06 #41

 P: n/a CBFalconer writes: pete wrote: pete wrote: Pedro Graca wrote: hi_mask = (UCHAR_MAX + 1) >> 1; is more portable? Not more portable, but slightly better style, perhaps. Actually, (UCHAR_MAX + 1) is not portable. If UCHAR_MAX is equal to UINT_MAX, then (hi_mask = (UCHAR_MAX + 1) >> 1) is equal to zero. and, if UCHAR_MAX is equal to INT_MAX, the expression creates undefined (or system defined) behaviour, due to the silly way that integer promotions work. Unsignedness is not preserved. It's unlikely that any real implementation would have UCHAR_MAX == INT_MAX. CHAR_BIT would have to be at least 15, and int would have to have exactly CHAR_BIT value bits (plus 1 sign bit), and therefore at least CHAR_BIT-1 padding bits (since the total number of bits must be a multiple of CHAR_BIT). Conforming, but silly. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Mar 24 '06 #42

 P: n/a jaysome said: Richard Heathfield wrote: jaysome said:Nor would I suspect that most other C programmers will [ever use asystem with CHAR_BIT > 8]. 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. Sure, but the kind of chips we're talking about are the very stuff of which embedded systems are made, and that's where most C work is being done. I would not be even remotely surprised if CHAR_BIT > 8 systems actually outnumbered CHAR_BIT = 8 systems. To be sure--a table impementation is fine as long as you understand the ramifications to portability. Absolutely. And I reiterate--most C programmers will be just fine, whether of not they understand the ramifications. Provided they stay away from the Real World, I agree entirely. -- 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) Mar 24 '06 #43

 P: n/a On 2006-03-24, Keith Thompson wrote: CBFalconer writes: pete wrote: pete wrote: Pedro Graca wrote:>> hi_mask = (UCHAR_MAX + 1) >> 1;>> is more portable? Not more portable, but slightly better style, perhaps. Actually, (UCHAR_MAX + 1) is not portable. If UCHAR_MAX is equal to UINT_MAX, then (hi_mask = (UCHAR_MAX + 1) >> 1) is equal to zero. and, if UCHAR_MAX is equal to INT_MAX, the expression creates undefined (or system defined) behaviour, due to the silly way that integer promotions work. Unsignedness is not preserved. It's unlikely that any real implementation would have UCHAR_MAX == INT_MAX. CHAR_BIT would have to be at least 15, and int would have to have exactly CHAR_BIT value bits (plus 1 sign bit), and therefore at least CHAR_BIT-1 padding bits (since the total number of bits must be a multiple of CHAR_BIT). Conforming, but silly. I'm not sure K&R gave any thought to odd ducks like this, any more than the case where single bits were addressable like the old (iirc) Borroughs machines. Mar 25 '06 #44

 P: n/a Richard Heathfield wrote: jaysome said:Richard Heathfield wrote:jaysome said: Nor would I suspect that most other C programmers will [ever use asystem with CHAR_BIT > 8]. Well, I certainly have used such an implementation, and so have a wholebunch of people I was working with at the time, and so has anyone elsewho has written C for the same chip, and so have lots of other peoplewriting C for other similar chips, too. And such chips, common a fewyears ago, are becoming yet more common all the time.Okay.But the fact that you and your co-workers and probably some of yourfriends and their friends have used such an implementation does nothardly qualify for "most" C programmers. Sure, but the kind of chips we're talking about are the very stuff of which embedded systems are made, and that's where most C work is being done. I would not be even remotely surprised if CHAR_BIT > 8 systems actually outnumbered CHAR_BIT = 8 systems. I'd be very surprised. Microchip: "grep" C:\HTSOFT\PIC18\include limits.h(3):#define CHAR_BIT 8 /* bits per char */ Atmel: "grep" C:\WINAVR limits.h(6):#define CHAR_BIT __CHAR_BIT__ __CHAR_BIT__ = 8 Between Microchip and Atmel, that's a lot of chips. And I reiterate--most C programmers willbe just fine, whether of not they understand the ramifications. Provided they stay away from the Real World, I agree entirely. And I reiterate--most C programmers will be just fine. When, and if, they ever get to develop with an implementation that defines CHAR_BIT > 8, and that makes a difference compared to CHAR_BIT = 8, "most" C programmers will directly or indirectly (e.g., via the testing group) force a result that leads them to conclude that their assumption about CHAR_BIT = 8 is invalid; subsequently, they would follow up with a resolution. That's my Real World, anyways. YMMV. -- jay Mar 25 '06 #45

 P: n/a jaysome opined: Richard Heathfield wrote: jaysome said:Richard Heathfield wrote:jaysome said: And I reiterate--most C programmers willbe just fine, whether of not they understand the ramifications. Provided they stay away from the Real World, I agree entirely. And I reiterate--most C programmers will be just fine. When, and if, they ever get to develop with an implementation that ^^^^^^^ What about "port old code"? defines CHAR_BIT > 8, and that makes a difference compared to CHAR_BIT = 8, "most" C programmers will directly or indirectly (e.g., via the testing group) force a result that leads them to conclude that their assumption about CHAR_BIT = 8 is invalid; subsequently, they would follow up with a resolution. Which, in case of "maintain old code" leads to endless hunt for all the places where integer constant 8 needs to be changed to 13. That's my Real World, anyways. YMMV. Not all people are lucky enough to have it easy, and do only green-field development. -- BR, Vladimir He knows not how to know who knows not also how to unknow. -- Sir Richard Burton Mar 25 '06 #46

### This discussion thread is closed

Replies have been disabled for this discussion.

### Similar topics

Browse more C / C++ Questions on Bytes