Re: KNF and the C preprocessor

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Consider the following code:

> #define cmd(n) \
>       if (__predict_true(ring_ptr < ring_end)) \
>               *ring_ptr++ = n; \
>       else { \
>               ring_ptr = ring; \
>               *ring_ptr++ = n; \
>               ring_wrap_count++; \
>       }

>       for (;;) {
>               if (__predict_false(...)) {
>                       if (...) {
>                               ....
>                               cmd(1);
>                               continue;
>                       }
>                       ...
>                       cmd(2);
>                       continue;
>               }
>               ...
>       }

> I want func() inlined twice so that there are only 2 conditional
> branches and usually a conditional branch in cmd() back to the loop
> top in each path.

Why?  (s/func/cmd/ I assume.)

> So I need to stop the compiler tail merging the two parts of the
> inside 'if'
> There is nothing I can put inside an inline function version of cmd()
> that will stop this happening.

There's nothing you can put in a macro that will prevent it, either.
Or, rather, as far as I can think of, anything you can do in a macro to
prevent it you can also do in an inline function.  If you have an
example of something that'll work one way but not the other I'd be
interested.

> In the #define version I can add things that stop the compiler
> merging the code.  Prizes for thinking what!

If you want control at that level of detail IMO you should be using
inline assembly.  Tradeoffs like that are not, in general, portable
between CPUs anyway; on some CPUs the if()s inside cmd() might not
generate any branches at all (both the assignment and the increment can
be done with conditional moves).  On others the branches may be cheaper
than the additional cache loads.

Not that I disagree with your conclusion as it applies to the original
issue; any dogmatic "Thou Shalt Not Use This Facility" ends up being
Procrustean one way or another.  I just think this is a bad example.

> Are some computer science courses teaching about optimisations that
> really haven't been true since the days of the m68k?

Are you under the impression that all computers are mass-market
desktops these days or something?  It was less than a year ago that I
heard from someone designing and building new hardware with a 386.
(Indeed, he said he was going to put NetBSD on it until I pointed out
that NetBSD had dropped support for the 386; I don't know whether he
went with something else or went with NetSBD old enough to still have
support for the 386.)  It wasn't all that long ago I bought a bunch of
(new) 8-bit CPUs, for that matter.

This is relevant because I doubt that there are any optimizations that
"haven't been true since the days of the m68k", and the existence and
use of machines of that ilk is why.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B