Macro that expand differently depending on the function calling it.

[Fabrice]

Hi,

Lets say I want to define a generic macro to swap bytes in a integer:
#define swapbytes(x) ...
I have several implementation of the macros, one is generic C, the
other one will be an optimized assembly version for a specific
architecture.

So I do something like that in swapbytes.h:

#ifdef __SOME_IMPLEMEN TATION_SPECIFIC _MACRO__
#define swapbytes(x) \
... some implementation defined assembly crap...
#else
#define swapbytes(x) \
... some generic C code ...
#endif

This works well and I can extend this to support many different
implementation dependent optimizations: MIPS, ARM, x86,...

Now i have an additional issue. In some case, I have two functions in
the same source files that requires two different implementations of
the macro. An example of such case is when you deal with arm thumb or
mips16 instruction set. Some implementation allows you to mix both
types of code, but my swapbytes macro would needs to be different for
both of them.

Is there any way to handle that while still keeping a generic include
file ?

Thanks

-- Fabrice

PS: If you think this is off-topic because I mention mips16 and thumb,
dont even bother replying.I think the C standard was designed to cope
with implementation specific extensions and issues like this.

[Jack Klein]

On Wed, 31 Oct 2007 00:53:34 -0000, Fabrice
<fa************ *@gmail.comwrot e in comp.lang.c:

Hi,

Lets say I want to define a generic macro to swap bytes in a integer:
#define swapbytes(x) ...
I have several implementation of the macros, one is generic C, the
other one will be an optimized assembly version for a specific
architecture.

So I do something like that in swapbytes.h:

#ifdef __SOME_IMPLEMEN TATION_SPECIFIC _MACRO__
#define swapbytes(x) \
... some implementation defined assembly crap...
#else
#define swapbytes(x) \
... some generic C code ...
#endif

This works well and I can extend this to support many different
implementation dependent optimizations: MIPS, ARM, x86,...

Now i have an additional issue. In some case, I have two functions in
the same source files that requires two different implementations of
the macro. An example of such case is when you deal with arm thumb or
mips16 instruction set. Some implementation allows you to mix both
types of code, but my swapbytes macro would needs to be different for
both of them.

Is there any way to handle that while still keeping a generic include
file ?

Thanks

-- Fabrice

PS: If you think this is off-topic because I mention mips16 and thumb,
dont even bother replying.I think the C standard was designed to cope
with implementation specific extensions and issues like this.

If you can provide proof from an Internationally recognized court of
law that has granted you supreme dictatorial powers over comp.lang.c,
and furthermore provide proof of that court's legal jurisdiction in
doing so, then you might attempt to forbid people who might dislike
your off-topic question from replying.

But I doubt if that would stop them. It certainly wouldn't stop me.

As for your incorrect belief about the C standard, and it is
incorrect, who gives a piece of bovine excrement?

*plonk*

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Ian Collins]

Fabrice wrote:

Hi,

Lets say I want to define a generic macro to swap bytes in a integer:
#define swapbytes(x) ...
I have several implementation of the macros, one is generic C, the
other one will be an optimized assembly version for a specific
architecture.

So I do something like that in swapbytes.h:

#ifdef __SOME_IMPLEMEN TATION_SPECIFIC _MACRO__
#define swapbytes(x) \
... some implementation defined assembly crap...
#else
#define swapbytes(x) \
... some generic C code ...
#endif

This works well and I can extend this to support many different
implementation dependent optimizations: MIPS, ARM, x86,...

Now i have an additional issue. In some case, I have two functions in
the same source files that requires two different implementations of
the macro. An example of such case is when you deal with arm thumb or
mips16 instruction set. Some implementation allows you to mix both
types of code, but my swapbytes macro would needs to be different for
both of them.

Why not just uses another macro, or better still, functions?

--
Ian Collins.

[Peter Nilsson]

Fabrice <fabrice.gaut.. [e-mail] e:

Lets say I want to define a generic macro to swap bytes
in a integer:
#define swapbytes(x) ...
I have several implementation of the macros, one is
generic C, the other one will be an optimized assembly
version for a specific architecture.

So I do something like that in swapbytes.h:

#ifdef __SOME_IMPLEMEN TATION_SPECIFIC _MACRO__
#define swapbytes(x) \
... some implementation defined assembly crap...
#else
#define swapbytes(x) \
... some generic C code ...
#endif

This works well and I can extend this to support many
different implementation dependent optimizations: MIPS,
ARM, x86,...

Now i have an additional issue. In some case, I have two
functions in the same source files that requires two
different implementations of the macro.

So use two macros.

#define swapbytes_speci al(a,b) ...

#if blah
#define swapbytes(a,b) swapbytes_speci al(a,b)
#elif ...
#define swapbytes(a,b) ...
#elif ...
#define swapbytes(a,b) ...
....
#endif

void foo() { ...swapbytes_sp ecial(a,b); ... }
void bar() { ...swapbytes(a, b); ...}

<snip>

PS: If you think this is off-topic because I mention
mips16 and thumb, dont even bother replying.

If it's off topic, don't bother posting. That way,
everyone wins.

I think the C standard was designed to cope with
implementation specific extensions and issues like
this.

Of course it is. But that doesn't mean that comp.lang.c
is the place to discus those extensions.

--
Peter

[Ark Khasin]

Fabrice wrote:

Hi,

Lets say I want to define a generic macro to swap bytes in a integer:
#define swapbytes(x) ...
I have several implementation of the macros, one is generic C, the
other one will be an optimized assembly version for a specific
architecture.

So I do something like that in swapbytes.h:

#ifdef __SOME_IMPLEMEN TATION_SPECIFIC _MACRO__
#define swapbytes(x) \
... some implementation defined assembly crap...
#else
#define swapbytes(x) \
... some generic C code ...
#endif

This works well and I can extend this to support many different
implementation dependent optimizations: MIPS, ARM, x86,...

Now i have an additional issue. In some case, I have two functions in
the same source files that requires two different implementations of
the macro. An example of such case is when you deal with arm thumb or
mips16 instruction set. Some implementation allows you to mix both
types of code, but my swapbytes macro would needs to be different for
both of them.

Is there any way to handle that while still keeping a generic include
file ?

Thanks

-- Fabrice

PS: If you think this is off-topic because I mention mips16 and thumb,
dont even bother replying.I think the C standard was designed to cope
with implementation specific extensions and issues like this.

#define swap(a,b) ((a)^=(b)^=(a)^ =(b))
Doesn't get much simpler than that. Why do you need platform-specific
hoop-jumping?

--
Ark

[pete]

Ark Khasin wrote:

#define swap(a,b) ((a)^=(b)^=(a)^ =(b))
Doesn't get much simpler than that.

That expression is no good.

N869
6.5 Expressions
[#2] Between the previous and next sequence point an object
shall have its stored value modified at most once by the
evaluation of an expression.

--
pete

[Ben Pfaff]

Ark Khasin <ak*****@macroe xpressions.comw rites:

#define swap(a,b) ((a)^=(b)^=(a)^ =(b))

Please read the FAQ.

3.3b: Here's a slick expression:

a ^= b ^= a ^= b

It swaps a and b without using a temporary.

A: Not portably, it doesn't. It attempts to modify the variable a
twice between sequence points, so its behavior is undefined.

For example, it has been reported that when given the code

int a = 123, b = 7654;
a ^= b ^= a ^= b;

the SCO Optimizing C compiler (icc) sets b to 123 and a to 0.

See also questions 3.1, 3.8, 10.3, and 20.15c.

(I don't endorse using products from SCO.)
--
Ben Pfaff
http://benpfaff.org

[Ark Khasin]

Ben Pfaff wrote:

Ark Khasin <ak*****@macroe xpressions.comw rites:

>#define swap(a,b) ((a)^=(b)^=(a)^ =(b))

Please read the FAQ.

3.3b: Here's a slick expression:

a ^= b ^= a ^= b

It swaps a and b without using a temporary.

A: Not portably, it doesn't. It attempts to modify the variable a
twice between sequence points, so its behavior is undefined.

For example, it has been reported that when given the code

int a = 123, b = 7654;
a ^= b ^= a ^= b;

the SCO Optimizing C compiler (icc) sets b to 123 and a to 0.

See also questions 3.1, 3.8, 10.3, and 20.15c.

(I don't endorse using products from SCO.)

OK. Got things wrong again. How about
#define swap(a,b) do{(a)^=(b); (b)^=(a); (a)^=(b);}while (0)
?
But all in all, I agree with FAQ 10.3: "If you're consumed by a
passionate desire to solve this problem once and for all, please
reconsider; there are better problems worthier of your energies."
--
Ark

[SM Ryan]

# OK. Got things wrong again. How about
# #define swap(a,b) do{(a)^=(b); (b)^=(a); (a)^=(b);}while (0)

Assume for example, that variable a is loaded in register R1, and
b in R2. On optimising compiler can potentially translate:

t = a; a = b; b = t;

into the assembly code:

No code at all, it simply relabels register R2 as a and R1 as b.
An optimiser could possibly realizes the exclusive ors are a swap,
or it might not, with three operations to do what it might have done
with zero operations if the intent of the programmer was clear.

# But all in all, I agree with FAQ 10.3: "If you're consumed by a
# passionate desire to solve this problem once and for all, please
# reconsider; there are better problems worthier of your energies."

Let the optimiser worry about cleverness. Write code that is obvious.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
You hate people.
But I love gatherings. Isn't it ironic.

[CBFalconer]

Ark Khasin wrote:

>

.... snip ...

>
OK. Got things wrong again. How about
#define swap(a,b) do{(a)^=(b); (b)^=(a); (a)^=(b);}while (0)
?
But all in all, I agree with FAQ 10.3: "If you're consumed by a
passionate desire to solve this problem once and for all, please
reconsider; there are better problems worthier of your energies."

Fails. Try:

int a = 5;
swap(a, a);

results in a == 0

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>
--
Posted via a free Usenet account from http://www.teranews.com