From: mikey@ontek.com (euphausia superba)
Newsgroups: comp.lang.c
Subject: Call For Pummeling: proposed "either-or" statement
Date: 21 Aug 92 17:48:01 GMT
Organization: Ontek Corporation -- Laguna Hills, California

Late at night in a slim-fast haze, I imagined the possible addition 
to C of an either-or construct which would serve the purposes of
portability and optimization.

The compiler would be free to choose whichever block of code compiles
"best" in its opinion, and would be obliged to at least issue warnings
for the code in the other blocks.  An error would result only if none
of the blocks compiles.  If more than one block compiles correctly, the
compiler and/or run time environment is free to alternate between the 
clauses a few times until it's obvious which one is faster.

  #include <stdio.h>
  void opine(void)
  {
    char * x = "To each his dentrifice.";

    either
      printf("%s\n", x);
    or
    {
      char * t;

      for (t = x; *t != '\0'; t++) putc(*t, stdout);
      putc("\n", stdout);
    }
    or
      printf printf roly poly printf;

    return;
  }

In the above example, the last or-clause would not compile and the
compiler would be obliged to issue a warning.  The two other blocks
would compile so there should be no error.  The compiler might be smart
enough to figure out which of the first two clauses was fastest or
compiled into the smallest code and choose only one, or it could add a
little more code which would try the printf method on one call and the
putc method on another.  Within a few iterations it should be clear
which is fastest.  And of course there might be some way to use this
information in a subsequent compilation.

I see some problems.  

1. The unpredictability about which clause would get executed
   could make testing difficult.  I would propose that a compiler
   switch could be invoked to alternate between clauses perpetually
   and/or randomly.

2. The overhead of extra instructions to do the alternation and
   choosing at run time might overshadow any differences between
   the either-or clauses.  To overcome this would require that
   the object text be modified at run time--this is a nono on
   some architectures and esthetically displeasing to some people.

3. On any given machine, it will probably be the case that one
   of the clauses is better under nearly all circumstances and
   the programmer should be more conscious of this.

4. This whole thing is a great way to make control freaks really
   nervous.

I see some advantages.

A. Code need not be polluted with #ifdef bsd or its moral
   equivalents.

B. Fewer machine-dependent trade-offs need to be made with regard to 
   hand-optimizing known bottlenecks.  A hack that works particularly
   well on some obscure machine might come into play again on some
   other not-so-obscure machine.

C. This whole thing is a great way to make control freaks really
   nervous.

Personally, I find the optimization feature more tantalizing
than the portability feature.  Granted, this level of
optimization should only be attempted after conclusive testing
with gprof or its moral equivalent has identified a true
bottleneck, but geez it's annoying to have to cater to one
instruction set when you finally do try to optimize.

So my question is: is there any prior art for this?  If so, what
happened to it and was it helpful?

     the krill

ps: net.hugs to all who recognize the string in the above code :)
Newsgroups: comp.lang.c