home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / c / 12641 < prev    next >
Encoding:
Text File  |  1992-08-21  |  3.4 KB  |  97 lines
  1. Path: sparky!uunet!ontek!mikey
  2. From: mikey@ontek.com (euphausia superba)
  3. Newsgroups: comp.lang.c
  4. Subject: Call For Pummeling: proposed "either-or" statement
  5. Message-ID: <2130@ontek.com>
  6. Date: 21 Aug 92 17:48:01 GMT
  7. Organization: Ontek Corporation -- Laguna Hills, California
  8. Lines: 87
  9.  
  10. Late at night in a slim-fast haze, I imagined the possible addition 
  11. to C of an either-or construct which would serve the purposes of
  12. portability and optimization.
  13.  
  14. The compiler would be free to choose whichever block of code compiles
  15. "best" in its opinion, and would be obliged to at least issue warnings
  16. for the code in the other blocks.  An error would result only if none
  17. of the blocks compiles.  If more than one block compiles correctly, the
  18. compiler and/or run time environment is free to alternate between the 
  19. clauses a few times until it's obvious which one is faster.
  20.  
  21.   #include <stdio.h>
  22.   void opine(void)
  23.   {
  24.     char * x = "To each his dentrifice.";
  25.  
  26.     either
  27.       printf("%s\n", x);
  28.     or
  29.     {
  30.       char * t;
  31.  
  32.       for (t = x; *t != '\0'; t++) putc(*t, stdout);
  33.       putc("\n", stdout);
  34.     }
  35.     or
  36.       printf printf roly poly printf;
  37.  
  38.     return;
  39.   }
  40.  
  41. In the above example, the last or-clause would not compile and the
  42. compiler would be obliged to issue a warning.  The two other blocks
  43. would compile so there should be no error.  The compiler might be smart
  44. enough to figure out which of the first two clauses was fastest or
  45. compiled into the smallest code and choose only one, or it could add a
  46. little more code which would try the printf method on one call and the
  47. putc method on another.  Within a few iterations it should be clear
  48. which is fastest.  And of course there might be some way to use this
  49. information in a subsequent compilation.
  50.  
  51. I see some problems.  
  52.  
  53. 1. The unpredictability about which clause would get executed
  54.    could make testing difficult.  I would propose that a compiler
  55.    switch could be invoked to alternate between clauses perpetually
  56.    and/or randomly.
  57.  
  58. 2. The overhead of extra instructions to do the alternation and
  59.    choosing at run time might overshadow any differences between
  60.    the either-or clauses.  To overcome this would require that
  61.    the object text be modified at run time--this is a nono on
  62.    some architectures and esthetically displeasing to some people.
  63.  
  64. 3. On any given machine, it will probably be the case that one
  65.    of the clauses is better under nearly all circumstances and
  66.    the programmer should be more conscious of this.
  67.  
  68. 4. This whole thing is a great way to make control freaks really
  69.    nervous.
  70.  
  71. I see some advantages.
  72.  
  73. A. Code need not be polluted with #ifdef bsd or its moral
  74.    equivalents.
  75.  
  76. B. Fewer machine-dependent trade-offs need to be made with regard to 
  77.    hand-optimizing known bottlenecks.  A hack that works particularly
  78.    well on some obscure machine might come into play again on some
  79.    other not-so-obscure machine.
  80.  
  81. C. This whole thing is a great way to make control freaks really
  82.    nervous.
  83.  
  84. Personally, I find the optimization feature more tantalizing
  85. than the portability feature.  Granted, this level of
  86. optimization should only be attempted after conclusive testing
  87. with gprof or its moral equivalent has identified a true
  88. bottleneck, but geez it's annoying to have to cater to one
  89. instruction set when you finally do try to optimize.
  90.  
  91. So my question is: is there any prior art for this?  If so, what
  92. happened to it and was it helpful?
  93.  
  94.      the krill
  95.  
  96. ps: net.hugs to all who recognize the string in the above code :)
  97.