I wrote:

> Using pointers, [a "bit 'a' = bit 'a' AND bit 'b'] operation could
> be performed with this line of code:
>
>    *a &= *b;
>
> With function calls, it looks like this:
>
>    WriteBit (Array1, a, Readbit (Array1,a) & Readbit (Array2,b));

and Martin J. Maney <PICLIST@MITVMA.MIT.EDU> replied:

> Well, yeah, but that's because you're comparing apples to oranges.
> The function call version is really the equivalent of
>
>   *a = *a & *b;                 /* without optimization */
>
> or the original ought to have been rephrased as
>
>   AndIntoBit(Array1, a, ReadBit(Array2, b));

Martin:

Ok... I'd be willing to change my first example to

    *a = *a & *b;

since even that slightly-expanded version still makes my point
rather convincingly.  Besides, most C compilers -- even the real
small ones -- will optimize that expression to "*a &= *b;" anyway.

Your second suggestion (writing individual functions for each
permissible bit operation), carries with it a host of problems with
which I'm INTIMATELY familiar, since my MPASM macros, discussion of
which started this thread, necessarily include individual "functions"
for reading, writing, ANDing, ORing, copying, etc.

Worse (and this is where the idea for writing individual
bit-manipulation functions completely breaks down), each of those
macros has to have at least two forms (and some have three forms) to
handle various combinations of literals in the inputs or outputs.

I can assure you that it's a pain in the ass to keep all the
assembly-language macros straight; do you really want to force that
pain on C programmers, too?

-Andy

Andrew Warren - fastfwd@ix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499