Macro Definitions and Usage

Hello everyone,

I have defined a MACRO as follows:

Code:

---

#define GET_BITS(bits, num_bits, bit)\
  if(num_bits > 0)\
  {\
      GET_BIT(bit);\    /* Gets one bit from a string of Bytes*/
      bits = bits | bit;\     
      while(0 < (num_bits-1))\
      {\
          bits = bits << 1;\
          GET_BIT(bit);\
          bits = bits | bit;\
          num_bits--;\
        }\
    }

---

usage:

Code:

---

int var=0;

XsGET_BITS(var, 3, 0);

---

my C Compiler had no problem compiling just the macro definition. However when I try to use this macro in one of my functions I get a compiler error that states the following.

"Invalid lvalue in assignment"

Can anyone point me in the right direction???

Thanks!

The macro uses num_bits as a variable but you give it a literal value.

More non-use of code tags - when will these people ever learn to read past their own question???

First off, this looks like it should definitely be a function instead of a macro.

Secondly, you should use parentheses around bits, num_bits, and bit inside the macro.

Thirdly, what does the GET_BIT macro look like?

The reason behind making this a Macro instead of a Function is for speed purposes.
Constantly making a function call to this routine would seriously affect my performance.

Code:

---

#define GET_BIT(ret_bit) \
      if(bit_counter == 32) \
      { \
          bit_counter = 0; \
          source_ptr++; \
        }
        bit_counter++;\
        ret_bit = bit_holder & 0x00000001;\
        bit_holder >>= 1;

---

bit_holder,
bit_counter,
source_ptr are ALL globals variables

Quote:

---

Originally Posted by edunia11

The reason behind making this a Macro instead of a Function is for speed purposes.
Constantly making a function call to this routine would seriously affect my performance.

---

Unless you are on an OLD OLD OLD OLD OLD OLD machine (like 8088) it would be very difficult to see a performace loss on loading a function.

If you look at the ammount of codepage required to constantly expand this code in-line and compare that to making the function call I believe you'd see it is almost nill. If not faster.

> The reason behind making this a Macro instead of a Function is for speed purposes
If your macro was a single statement, you might have a point.
But it's a nested macro with a while loop in it, so I'd say you're blowing all the issues out of proportion.

Write it first, get it working and tested with real world data.
Then profile it to find out where the real hot spots are, not the ones you imagine.
Then make careful changes which you can prove produce the same results AND give a useful performance improvement.

Until then, you're just wasting time bastardising the code structure just to satisfy your preconceived notions of performance.

Like someone said, it doesn't matter how much you write your bubble sort in assembler, it will still suck.

Besides, there are more efficient ways of extracting 'n' consecutive bits from a bit-stream than one at a time. With a bit of though, you should be able to split 'n' into 'x' + 'y' bits, and with careful use of masks and shifts extract all 'x' bits from word1 and all 'y' bits from word2 and combine both results with just a few & >> << and | operations.

Quote:

---

Originally Posted by Salem

>With a bit of though, you should be able to split 'n' into 'x' + 'y' bits, and with careful use of masks and shifts extract all 'x' bits from word1 and all 'y' bits from word2 and combine both results with just a few & >> << and | operations.

---

Shame on you. . . you give too much basic-level information ;).

The code HAS been tested using routines and not MACROS, I'm just trying to get a little bit of an edge using macros, since my performance is so awful.

Thanks for all of your suggestions.

Quote:

---

Originally Posted by edunia11

The code HAS been tested using routines and not MACROS, I'm just trying to get a little bit of an edge using macros, since my performance is so awful.

Thanks for all of your suggestions.

---

Like Salem said, using a better (read: smarter) algorithm would be a lot better than macro-izing the routine.

>I'm just trying to get a little bit of an edge using macros, since my performance is so awful.
If your performance is that bad, I seriously doubt the difference is in function call overhead.

> The code HAS been tested using routines and not MACROS
To paraphrase Raiders of the Lost Ark, "you're digging in the wrong place!"
Which is generally what happens when you use the wrong measuring stick.

> I'm just trying to get a little bit of an edge using macros, since my performance is so awful.
So you're looking for a 10x performance?
That comes from choosing a better algorithm, not from implementing MACRO hell.

Sorry, I can't help but mention this and this.