# to unbundle, sh this file (in an empty directory)
echo RATIONALE 1>&2
sed >RATIONALE <<'//GO.SYSIN DD RATIONALE' 's/^-//'
-
-
-    Dhrystone Benchmark: Rationale for Version 2 and Measurement Rules
-
-        [published in SIGPLAN Notices 23,8 (Aug. 1988), 49-62]
-
-
-                 Reinhold P. Weicker
-                 Siemens AG, E STE 35
-                 [now: Siemens AG, AUT E 51]
-                 Postfach 3220
-                 D-8520 Erlangen
-                 Germany (West)
-
-
-
-
-1.  Why a Version 2 of Dhrystone?
-
-The Dhrystone benchmark  program  [1]  has  become  a  popular  benchmark  for
-CPU/compiler   performance   measurement,   in   particular  in  the  area  of
-minicomputers, workstations, PC's and microprocesors.  It apparently satisfies
-a  need  for  an  easy-to-use  integer benchmark; it gives a first performance
-indication which is more meaningful than MIPS numbers which, in their  literal
-meaning  (million  instructions  per  second), cannot be used across different
-instruction sets (e.g. RISC  vs.  CISC).   With  the  increasing  use  of  the
-benchmark, it seems necessary to reconsider the benchmark and to check whether
-it can still fulfill this function.  Version 2 of Dhrystone is the  result  of
-such a re-evaluation, it has been made for two reasons:
-
-o Dhrystone has been published in Ada [1], and Versions in Ada, Pascal  and  C
-  have  been  distributed  by  Reinhold Weicker via floppy disk.  However, the
-  version that was used most often for benchmarking has been the version  made
-  by  Rick  Richardson  by another translation from the Ada version into the C
-  programming language, this has been the version  distributed  via  the  UNIX
-  network Usenet [2].
-
-  There is an obvious need for a common C version of Dhrystone, since C is  at
-  present  the  most  popular  system  programming  language  for the class of
-  systems (microcomputers, minicomputers,  workstations)  where  Dhrystone  is
-  used  most.   There  should  be,  as  far as possible, only one C version of
-  Dhrystone such that results can be compared  without  restrictions.  In  the
-  past,  the  C  versions  distributed by Rick Richardson (Version 1.1) and by
-  Reinhold Weicker had small (though not significant) differences.
-
-  Together with the new C version, the  Ada  and  Pascal  versions  have  been
-  updated as well.
-
-o As far as it is  possible  without  changes  to  the  Dhrystone  statistics,
-  optimizing   compilers   should   be  prevented  from  removing  significant
-  statements.  It has  turned  out  in  the  past  that  optimizing  compilers
-  suppressed  code  generation for too many statements (by "dead code removal"
-  or  "dead  variable  elimination").   This  has  lead  to  the  danger  that
-  benchmarking  results obtained by a naive application of Dhrystone - without
-  inspection of the code that was generated - could become meaningless.
-
-The  overall  policiy  for  version  2  has  been  that  the  distribution  of
-statements,  operand types and operand locality described in [1] should remain
-unchanged as much as possible.  (Very few changes were necessary; their impact
-should be negligible.)  Also, the order of statements should remain unchanged.
-Although I am aware of some critical remarks on the benchmark - I  agree  with
-several  of them - and know some suggestions for improvement, I didn't want to
-change the benchmark into something different from what has  become  known  as
-"Dhrystone"; the confusion generated by such a change would probably outweight
-the benefits. If I were to write a new benchmark program, I wouldn't  give  it
-the  name  "Dhrystone"  since  this  denotes  the  program  published  in [1].
-However, I do recognize  the  need  for  a  larger  number  of  representative
-programs  that can be used as benchmarks; users should always be encouraged to
-use more than just one benchmark.
-
-The new versions (version 2.1 for C, Pascal and Ada) will  be  distributed  as
-widely as possible.  (Version 2.1 differs from version 2.0 distributed via the
-UNIX Network Usenet in  March  1988  only  in  a  few  corrections  for  minor
-deficiencies  found  by  users  of  version 2.0.)  Readers who want to use the
-benchmark for their own measurements can obtain  a  copy  in  machine-readable
-form on floppy disk (MS-DOS or XENIX format) from the author.
-
-
-2.  Overall Characteristics of Version 2
-
-In general, version 2  follows  -  in  the  parts  that  are  significant  for
-performance  measurement,  i.e.   within  the measurement loop - the published
-(Ada) version and the C versions previously distributed.  Where  the  versions
-distributed  by  Rick Richardson [2] and Reinhold Weicker have been different,
-it  follows  the  version  distributed  by  Reinhold  Weicker.  (However,  the
-differences  have  been  so  small  that their impact on execution time in all
-likelihood has been negligible.)  The initialization and UNIX  instrumentation
-part  -  which  had  been  omitted  in  [1] - follows mostly the ideas of Rick
-Richardson [2].  However, any changes in the initialization part  and  in  the
-printing  of  the  result have no impact on performance measurement since they
-are outside the measaurement loop.  As a concession to older compilers,  names
-have been made unique within the first 8 characters for the C version.
-
-The original publication of Dhrystone did not contain any statements for  time
-measurement  since  they  are necessarily system-dependent. However, it turned
-out that it is not enough just to inclose the main procedure of Dhrystone in a
-loop  and  to  measure the execution time.  If the variables that are computed
-are not used somehow, there is the danger that the compiler considers them  as
-"dead  variables" and suppresses code generation for a part of the statements.
-Therefore in version 2 all variables of "main" are printed at the end  of  the
-program.  This also permits some plausibility control for correct execution of
-the benchmark.
-
-At several places in the benchmark, code has been added, but only in  branches
-that  are  not  executed. The intention is that optimizing compilers should be
-prevented from moving code out of the measurement loop, or from removing  code
-altogether.  Statements that are executed have been changed in very few places
-only.  In these cases, only the role of some operands has been changed, and it
-was   made  sure  that  the  numbers  defining  the  "Dhrystone  distribution"
-(distribution of statements, operand types and locality) still hold as much as
-possible.   Except for sophisticated optimizing compilers, execution times for
-version 2.1 should be the same as for previous versions.
-
-Because of the self-imposed limitation that the order and distribution of  the
-executed  statements  should  not  be  changed,  there  are  still cases where
-optimizing compilers may not generate code for some statements. To  a  certain
-degree,  this  is  unavoidable  for  small synthetic benchmarks.  Users of the
-benchmark are advised to check code listings whether code is generated for all
-statements of Dhrystone.
-
-Contrary to the suggestion in the published paper and its realization  in  the
-versions previously distributed, no attempt has been made to subtract the time
-for the measurement loop overhead. (This calculation has proven  difficult  to
-implement  in  a  correct  way,  and  its omission makes the program simpler.)
-However, since the loop check is now part of the benchmark, this does have  an
-impact  -  though a very minor one - on the distribution statistics which have
-been updated for this version.
-
-
-3.  Discussion of Individual Changes
-
-In this section, all changes are described that affect  the  measurement  loop
-and  that  are  not  just  renamings  of variables. All remarks refer to the C
-version; the other language versions have been updated similarly.
-
-In addition to adding  the  measurement  loop  and  the  printout  statements,
-changes have been made at the following places:
-
-o In procedure "main", three statements have been added  in  the  non-executed
-  "then" part of the statement
-
-        if (Enum_Loc == Func_1 (Ch_Index, 'C'))
-
-  they are
-
-        strcpy (Str_2_Loc, "DHRYSTONE PROGRAM, 3'RD STRING");
-        Int_2_Loc = Run_Index;
-        Int_Glob = Run_Index;
-
-  The string assignment prevents  movement  of  the  preceding  assignment  to
-  Str_2_Loc  (5'th  statement  of  "main")  out  of the measurement loop (This
-  probably will not happen for the C version, but it did happen  with  another
-  language   and  compiler.)   The  assignment  to  Int_2_Loc  prevents  value
-  propagation for Int_2_Loc, and the assignment to Int_Glob makes the value of
-  Int_Glob possibly dependent from the value of Run_Index.
-
-o In the three arithmetic computations at the end of the measurement  loop  in
-  "main  ",  the  role  of  some  variables has been exchanged, to prevent the
-  division from just cancelling out the multiplication as it was  in  [1].   A
-  very   smart  compiler  might  have  recognized  this  and  suppressed  code
-  generation for the division.
-
-o For Proc_2, no code has been changed, but the values of the actual parameter
-  have changed due to changes in "main".
-
-o In Proc_4, the second assignment has been changed from
-
-        Bool_Loc = Bool_Loc | Bool_Glob;
-
-  to
-
-        Bool_Glob = Bool_Loc | Bool_Glob;
-
-  It now assigns a value to a global variable  instead  of  a  local  variable
-  (Bool_Loc);   Bool_Loc  would  be  a  "dead  variable"  which  is  not  used
-  afterwards.
-
-o In Func_1, the statement
-
-        Ch_1_Glob = Ch_1_Loc;
-
-  was added in the non-executed "else" part of the "if" statement, to  prevent
-  the suppression of code generation for the assignment to Ch_1_Loc.
-
-o In Func_2, the second character comparison statement has been changed to
-
-        if (Ch_Loc == 'R')
-
-  ('R' instead of 'X') because  a  comparison  with  'X'  is  implied  in  the
-  preceding "if" statement.
-
-  Also in Func_2, the statement
-
-        Int_Glob = Int_Loc;
-
-  has been added in the non-executed part of the last "if" statement, in order
-  to prevent Int_Loc from becoming a dead variable.
-
-o In Func_3, a non-executed "else" part has been added to the "if"  statement.
-  While  the  program  would  not be incorrect without this "else" part, it is
-  considered bad programming practice if a function  can  be  left  without  a
-  return value.
-
-  To compensate for this change, the (non-executed) "else" part  in  the  "if"
-  statement of Proc_3 was removed.
-
-The distribution statistics have been changed only  by  the  addition  of  the
-measurement loop iteration (1 additional statement, 4 additional local integer
-operands) and by the change in Proc_4  (one  operand  changed  from  local  to
-global).  The distribution statistics in the comment headers have been updated
-accordingly.
-
-
-4.  String Operations
-
-The string operations (string assignment and string comparison) have not  been
-changed, to keep the program consistent with the original version.
-
-There has been some concern that the string operations are over-represented in
-the  program,  and that execution time is dominated by these operations.  This
-was true in particular when optimizing compilers removed too much code in  the
-main part of the program, this should have been mitigated in version 2.
-
-It should be noted that this is a  language-dependent  issue:   Dhrystone  was
-first  published  in  Ada, and with Ada or Pascal semantics, the time spent in
-the string operations is,  at  least  in  all  implementations  known  to  me,
-considerably smaller.  In Ada and Pascal, assignment and comparison of strings
-are operators defined in the language, and the upper  bounds  of  the  strings
-occuring  in  Dhrystone  are part of the type information known at compilation
-time.  The compilers can therefore generate  efficient  inline  code.   In  C,
-string  assignemt  and comparisons are not part of the language, so the string
-operations must be expressed in terms of the C library functions "strcpy"  and
-"strcmp".   (ANSI  C  allows  an  implementation  to use inline code for these
-functions.)  In addition to the overhead caused by additional function  calls,
-these  functions  are  defined for null-terminated strings where the length of
-the strings is not known at compilation time; the function has to check  every
-byte for the termination condition (the null byte).
-
-Obviously, a C library which includes efficiently coded "strcpy" and  "strcmp"
-functions  helps to obtain good Dhrystone results. However, I don't think that
-this is unfair since string  functions  do  occur  quite  frequently  in  real
-programs  (editors, command interpreters, etc.).  If the strings functions are
-implemented efficiently,  this  helps  real  programs  as  well  as  benchmark
-programs.
-
-I admit that the  string  comparison  in  Dhrystone  terminates  later  (after
-scanning  20  characters)  than most string comparisons in real programs.  For
-consistency with the original benchmark, I didn't change the  program  despite
-this weakness.
-
-
-5.  Intended Use of Dhrystone
-
-When Dhrystone is used, the following "ground rules" apply:
-
-o Separate compilation (Ada and C versions)
-
-  As mentioned in [1], Dhrystone was written  to  reflect  actual  programming
-  practice  in  systems  programming.   The  division into several compilation
-  units (5 in the Ada version, 2 in the C version)  is  intended,  as  is  the
-  distribution of inter-module and intra-module subprogram calls.  Although on
-  many systems there will be no difference in execution time  to  a  Dhrystone
-  version  where  all  compilation units are merged into one file, the rule is
-  that separate compilation should  be  used.   The  intention  is  that  real
-  programming  practice,  where  programs  consist  of  several  independently
-  compiled units, should  be  reflected.   This  also  has  implies  that  the
-  compiler,  while  compiling  one  unit,  has no information about the use of
-  variables, register allocation etc.  occuring in  other  compilation  units.
-  Although  in  real  life  compilation  units  will  probably  be larger, the
-  intention is that these effects  of  separate  compilation  are  modeled  in
-  Dhrystone.
-
-  A few language systems have post-linkage optimization available (e.g., final
-  register allocation is performed after linkage).  This is a borderline case:
-  Post-linkage  optimization  involves  additional  program  preparation  time
-  (although  not  as  much  as  compilation in one unit) which may prevent its
-  general use in practical programming.  I think that  since  it  defeats  the
-  intentions given above, it should not be used for Dhrystone.
-
-  Unfortunately, ISO/ANSI  Pascal  does  not  contain  language  features  for
-  separate  compilation.   Although  most  commercial Pascal compilers provide
-  separate compilation in some way, we cannot use it for Dhrystone since  such
-  a  version  would  not  be portable.  Therefore, no attempt has been made to
-  provide a Pascal version with several compilation units.
-
-o No procedure merging
-
-  Although Dhrystone contains some very short procedures where execution would
-  benefit  from  procedure  merging (inlining, macro expansion of procedures),
-  procedure merging is not to be used.  The reason is that the  percentage  of
-  procedure  and  function  calls  is  part of the "Dhrystone distribution" of
-  statements contained in [1].  This restriction does not hold for the  string
-  functions  of  the  C  version  since ANSI C allows an implementation to use
-  inline code for these functions.
-
-o Other optimizations are allowed, but they should be indicated
-
-  It is often hard to draw an exact line between "normal code generation"  and
-  "optimization"  in  compilers:  Some compilers perform operations by default
-  that are invoked in other compilers only  when  optimization  is  explicitly
-  requested.  Also, we cannot avoid that in benchmarking people try to achieve
-  results that look as good as possible.  Therefore,  optimizations  performed
-  by  compilers  -  other  than  those  listed  above - are not forbidden when
-  Dhrystone execution times are measured.  Dhrystone is  not  intended  to  be
-  non-optimizable  but  is  intended  to  be  similarly  optimizable as normal
-  programs.   For  example,  there  are  several  places  in  Dhrystone  where
-  performance   benefits   from   optimizations   like   common  subexpression
-  elimination, value  propagation  etc.,  but  normal  programs  usually  also
-  benefit  from  these  optimizations.   Therefore,  no  effort  was  made  to
-  artificially  prevent  such  optimizations.   However,  measurement  reports
-  should  indicate  which  compiler  optimization  levels  have been used, and
-  reporting results with different levels of  compiler  optimization  for  the
-  same hardware is encouraged.
-
-o Default results are those without "register" declarations (C version)
-
-  When Dhrystone results are quoted  without  additional  qualification,  they
-  should  be  understood  as  results  obtained  without use of the "register"
-  attribute. Good compilers should be able to make good use of registers  even
-  without explicit register declarations ([3], p. 193).
-
-Of course, for experimental  purposes,  post-linkage  optimization,  procedure
-merging and/or compilation in one unit can be done to determine their effects.
-However,  Dhrystone  numbers  obtained  under  these  conditions   should   be
-explicitly  marked as such; "normal" Dhrystone results should be understood as
-results obtained following the ground rules listed above.
-
-In any case, for serious performance evaluation, users are advised to ask  for
-code  listings  and  to  check  them carefully.  In this way, when results for
-different systems are  compared,  the  reader  can  get  a  feeling  how  much
-performance  difference is due to compiler optimization and how much is due to
-hardware speed.
-
-
-6.  Acknowledgements
-
-The C version 2.1 of Dhrystone has been developed  in  cooperation  with  Rick
-Richardson  (Tinton  Falls,  NJ), it incorporates many ideas from the "Version
-1.1" distributed previously by him over the UNIX network Usenet.  Through  his
-activity with Usenet, Rick Richardson has made a very valuable contribution to
-the dissemination of the benchmark.  I also thank  Chaim  Benedelac  (National
-Semiconductor),  David Ditzel (SUN), Earl Killian and John Mashey (MIPS), Alan
-Smith and Rafael  Saavedra-Barrera  (UC  at  Berkeley)  for  their  help  with
-comments on earlier versions of the benchmark.
-
-
-7.  Bibliography
-
-[1]
-   Reinhold P. Weicker: Dhrystone: A Synthetic Systems Programming Benchmark.
-   Communications of the ACM 27, 10 (Oct. 1984), 1013-1030
-
-[2]
-   Rick Richardson: Dhrystone 1.1 Benchmark Summary (and Program Text)
-   Informal Distribution via "Usenet", Last Version Known  to  me:  Sept.  21,
-   1987
-
-[3]
-   Brian W. Kernighan and Dennis M. Ritchie:  The C Programming Language.
-   Prentice-Hall, Englewood Cliffs (NJ) 1978
-
//GO.SYSIN DD RATIONALE
echo README_C 1>&2
sed >README_C <<'//GO.SYSIN DD README_C' 's/^-//'
-This "shar" file contains the documentation for the
-electronic mail distribution of the Dhrystone benchmark (C version 2.1);
-a companion "shar" file contains the source code.
-(Because of mail length restrictions for some mailers, I have
-split the distribution in two parts.)
-
-For versions in other languages, see the other "shar" files.
-
-Files containing the C version (*.h: Header File, *.c: C Modules)
-
-  dhry.h
-  dhry_1.c
-  dhry_2.c
-  
-The file RATIONALE contains the article 
-
-  "Dhrystone Benchmark: Rationale for Version 2 and Measurement Rules"
-
-which has been published, together with the C source code (Version 2.0),
-in SIGPLAN Notices vol. 23, no. 8 (Aug. 1988), pp. 49-62.
-This article explains all changes that have been made for Version 2,
-compared with the version of the original publication
-in Communications of the ACM vol. 27, no. 10 (Oct. 1984), pp. 1013-1030.
-It also contains "ground rules" for benchmarking with Dhrystone
-which should be followed by everyone who uses the program and publishes
-Dhrystone results.
-
-Compared with the Version 2.0 published in SIGPLAN Notices, Version 2.1
-contains a few corrections that have been made after Version 2.0 was
-distriobuted over the UNIX network Usenet. These small differences between
-Version 2.0 and 2.1 should not affect execution time measurements.
-For those who want to compare the exact contents of both versions,
-the file "dhry_c.dif" contains the differences between the two versions,
-as generated by a file comparison of the corresponding files with the
-UNIX utility "diff".
-
-The file VARIATIONS contains the article
-
-  "Understanding Variations in Dhrystone Performance"
-
-which has been published in Microprocessor Report, May 1989
-(Editor: M. Slater), pp. 16-17. It describes the points that users
-should know if C Dhrystone results are compared.
-
-Recipients of this shar file who perform measurements are asked
-to send measurement results to the author and/or to Rick Richardson.
-Rick Richardson publishes regularly Dhrystone results on the UNIX network
-Usenet. For submissions of results to him (preferably by electronic mail,
-see address in the program header), he has provided a form which is contained
-in the file "submit.frm".
-
-
-The following files are contained in other "shar" files:
-
-Files containing the Ada version (*.s: Specifications, *.b: Bodies):
-
-  d_global.s
-  d_main.b
-  d_pack_1.b
-  d_pack_1.s
-  d_pack_2.b
-  d_pack_2.s
-
-File containing the Pascal version:
-
-  dhry.p
-
-
-February 22, 1990
-
-                 Reinhold P. Weicker
-                 Siemens AG, AUT E 51
-                 Postfach 3220
-                 D-8520 Erlangen
-                 Germany (West)
-
-                 Phone:  [xxx-49]-9131-7-20330  (8-17 Central European Time)
-                 UUCP:   ..!mcsun!unido!estevax!weicker
//GO.SYSIN DD README_C
echo VARIATIONS 1>&2
sed >VARIATIONS <<'//GO.SYSIN DD VARIATIONS' 's/^-//'
-
-            Understanding Variations in Dhrystone Performance
-
-
-
-          By Reinhold P. Weicker, Siemens AG, AUT E 51, Erlangen
-
-
-
-                                April 1989
-
-
-                      This article has appeared in:
-
-
-        Microprocessor Report, May 1989 (Editor: M. Slater), pp. 16-17
-
-
-
-
-Microprocessor manufacturers tend to credit all the  performance  measured  by
-benchmarks to the speed of their processors, they often don't even mention the
-programming language and compiler used. In their detailed  documents,  usually
-called  "performance brief" or "performance report," they usually do give more
-details. However, these details are often lost in the press releases and other
-marketing  statements.  For serious performance evaluation, it is necessary to
-study the code generated by the various compilers.
-
-Dhrystone was originally published in Ada (Communications  of  the  ACM,  Oct.
-1984).  However, since good Ada compilers were rare at this time and, together
-with UNIX, C became more and more popular, the C version of Dhrystone  is  the
-one  now  mainly  used in industry. There are "official" versions 2.1 for Ada,
-Pascal, and C,  which  are  as  close  together  as  the  languages'  semantic
-differences permit.
-
-Dhrystone contains two statements  where  the  programming  language  and  its
-translation play a major part in the execution time measured by the benchmark:
-
-  o   String assignment (in procedure Proc_0 / main)
-  o   String comparison (in function Func_2)
-
-In Ada and Pascal, strings are arrays of characters where the  length  of  the
-string  is  part  of the type information known at compile time. In C, strings
-are also arrays of characters, but there  are  no  operators  defined  in  the
-language  for  assignment  and  comparison  of  strings.   Instead,  functions
-"strcpy" and "strcmp" are used. These functions are  defined  for  strings  of
-arbitrary  length, and make use of the fact that strings in C have to end with
-a terminating null byte. For general-purpose calls  to  these  functions,  the
-implementor  can  assume  nothing  about  the  length and the alignment of the
-strings involved.
-
-The C version of Dhrystone spends a relatively large amount of time  in  these
-two  functions.  Some  time  ago, I made measurements on a VAX 11/785 with the
-Berkeley UNIX (4.2) compilers (often-used compilers,  but  certainly  not  the
-most  advanced).  In  the  C  version, 23% of the time was spent in the string
-functions; in the Pascal version, only 10%. On good RISC machines (where  less
-time is spent in the procedure calling sequence than on a VAX) and with better
-optimizing compilers, the percentage is higher; MIPS has reported 34%  for  an
-R3000.   Because  of this effect, Pascal and Ada Dhrystone results are usually
-better than C results (except when the optimization quality of the C  compiler
-is considerably better than that of the other compilers).
-
-Several people have noted that the string operations are  over-represented  in
-Dhrystone,  mainly  because the strings occurring in Dhrystone are longer than
-average strings. I admit that this is true, and have said  so  in  my  SIGPLAN
-Notices  paper  (Aug.  1988);  however, I didn't want to generate confusion by
-changing the string lengths from version 1 to version 2.
-
-Even if they are somewhat over-represented in Dhrystone, string operations are
-frequent  enough  that  it makes sense to implement them in the most efficient
-way possible, not only for benchmarking purposes.  This means  that  they  can
-and should be written in assembly language code. ANSI C also explicitly allows
-the strings functions to be implemented as macros, i.e. by inline code.
-
-There is also a third way to speed up the "strcpy" statement in Dhrystone: For
-this  particular  "strcpy" statement, the source of the assignment is a string
-constant. Therefore, in contrast to calls to "strcpy" in the general case, the
-compiler  knows  the  length  and alignment of the strings involved at compile
-time and can generate code in the same efficient  way  as  a  Pascal  compiler
-(word instructions instead of byte instructions).
-
-This is not allowed in the case of the "strcmp" call: Here, the addresses  are
-formal  procedure  parameters, and no assumptions can be made about the length
-or alignment of the strings.  Any such assumptions would indicate an incorrect
-implementation.  They  might work for Dhrystone, where the strings are in fact
-word-aligned  with  typical  compilers,  but  other  programs  would   deliver
-incorrect results.
-
-So, for an apple-to-apple  comparison  between  processors,  and  not  between
-several  possible  (legal  or  illegal)  degrees of compiler optimization, one
-should check that the systems are comparable with  respect  to  the  following
-three points:
-
-  (1) String functions in assembly language vs. in C
-
-      Frequently used functions such as the string functions can and should be
-      written  in  assembly language, and all serious C language systems known
-      to me do this. (I list this point  for  completeness  only.)  Note  that
-      processors  with an instruction that checks a word for a null byte (such
-      as AMD's  29000  and  Intel's  80960)  have  an  advantage  here.  (This
-      advantage  decreases  relatively if optimization (3) is applied.) Due to
-      the length of the strings involved in Dhrystone, this advantage  may  be
-      considered  too  high  in  perspective, but it is certainly legal to use
-      such instructions - after all,  these  situations  are  what  they  were
-      invented for.
-
-  (2) String function code inline vs. as library functions.
-
-      ANSI  C  has  created  a  new  situation,  compared   with   the   older
-      Kernighan/Ritchie  C.  In  the  original C, the definition of the string
-      function was not part of the  language.  Now  it  is,  and  inlining  is
-      explicitly  allowed.  I  probably  should have stated more clearly in my
-      SIGPLAN  Notices  paper  that  the  rule  "No  procedure  inlining   for
-      Dhrystone"  referred  to  the  user level procedures only and not to the
-      library routines.
-
-  (3) Fixed-length and alignment assumptions for the strings
-
-      Compilers should be allowed to optimize in these cases if (and only  if)
-      it  is safe to do so. For Dhrystone, this is the "strcpy" statement, but
-      not the  "strcmp"  statement  (unless,  of  course,  the  "strcmp"  code
-      explicitly   checks   the  alignment  at  execution  time  and  branches
-      accordingly).  A "Dhrystone switch" for the  compiler  that  causes  the
-      generation  of  code  that  may  not work under certain circumstances is
-      certainly inappropriate for comparisons. It has been reported in  Usenet
-      that some C compilers provide such a compiler option; since I don't have
-      access to all C compilers involved, I cannot verify this.
-
-      If the fixed-length and word-alignment assumption can be  used,  a  wide
-      bus  that permits fast multi-word load instructions certainly does help;
-      however, this fact by itself should not make a really big difference.
-
-A check of  these  points  -  something  that  is  necessary  for  a  thorough
-evaluation  and  comparison  of  the  Dhrystone  performance claims - requires
-object code listings as well as listings for  the  string  functions  (strcpy,
-strcmp) that are possibly called by the program.
-
-I don't pretend that Dhrystone is  a  perfect  tool  to  measure  the  integer
-performance  of microprocessors. The more it is used and discussed, the more I
-myself learn about aspects that I hadn't noticed yet when I wrote the program.
-And  of  course,  the  very success of a benchmark program is a danger in that
-people may tune their compilers and/or hardware to it, and  with  this  action
-make it less useful.
-
-Whetstone and Linpack have their critical points also:  The  Whetstone  rating
-depends  heavily on the speed of the mathematical functions (sine, sqrt, ...),
-and Linpack is sensitive to data alignment for some cache configurations.
-
-Introduction of a standard set of public domain benchmark software  (something
-the  SPEC  effort attempts) is certainly a worthwhile thing.  In the meantime,
-people will continue to use whatever is available and widely distributed,  and
-Dhrystone  ratings  are probably still better than MIPS ratings if these are -
-as often in industry - based on  no  reproducible  derivation.   However,  any
-serious  performance  evaluation  requires  more than just a comparison of raw
-numbers; one has to make sure  that  the  numbers  have  been  obtained  in  a
-comparable way.
-
//GO.SYSIN DD VARIATIONS
echo dhry.h 1>&2
sed >dhry.h <<'//GO.SYSIN DD dhry.h' 's/^-//'
-/*
- ****************************************************************************
- *
- *                   "DHRYSTONE" Benchmark Program
- *                   -----------------------------
- *                                                                            
- *  Version:    C, Version 2.1
- *                                                                            
- *  File:       dhry.h (part 1 of 3)
- *
- *  Date:       May 25, 1988
- *
- *  Author:     Reinhold P. Weicker
- *                      Siemens AG, AUT E 51
- *                      Postfach 3220
- *                      8520 Erlangen
- *                      Germany (West)
- *                              Phone:  [+49]-9131-7-20330
- *                                      (8-17 Central European Time)
- *                              Usenet: ..!mcsun!unido!estevax!weicker
- *
- *              Original Version (in Ada) published in
- *              "Communications of the ACM" vol. 27., no. 10 (Oct. 1984),
- *              pp. 1013 - 1030, together with the statistics
- *              on which the distribution of statements etc. is based.
- *
- *              In this C version, the following C library functions are used:
- *              - strcpy, strcmp (inside the measurement loop)
- *              - printf, scanf (outside the measurement loop)
- *              In addition, Berkeley UNIX system calls "times ()" or "time ()"
- *              are used for execution time measurement. For measurements
- *              on other systems, these calls have to be changed.
- *
- *  Collection of Results:
- *              Reinhold Weicker (address see above) and
- *              
- *              Rick Richardson
- *              PC Research. Inc.
- *              94 Apple Orchard Drive
- *              Tinton Falls, NJ 07724
- *                      Phone:  (201) 389-8963 (9-17 EST)               
- *                      Usenet: ...!uunet!pcrat!rick
- *
- *      Please send results to Rick Richardson and/or Reinhold Weicker.
- *      Complete information should be given on hardware and software used.
- *      Hardware information includes: Machine type, CPU, type and size
- *      of caches; for microprocessors: clock frequency, memory speed
- *      (number of wait states).
- *      Software information includes: Compiler (and runtime library)
- *      manufacturer and version, compilation switches, OS version.
- *      The Operating System version may give an indication about the
- *      compiler; Dhrystone itself performs no OS calls in the measurement loop.
- *
- *      The complete output generated by the program should be mailed
- *      such that at least some checks for correctness can be made.
- *
- ***************************************************************************
- *
- *  History:    This version C/2.1 has been made for two reasons:
- *
- *              1) There is an obvious need for a common C version of
- *              Dhrystone, since C is at present the most popular system
- *              programming language for the class of processors
- *              (microcomputers, minicomputers) where Dhrystone is used most.
- *              There should be, as far as possible, only one C version of
- *              Dhrystone such that results can be compared without
- *              restrictions. In the past, the C versions distributed
- *              by Rick Richardson (Version 1.1) and by Reinhold Weicker
- *              had small (though not significant) differences.
- *
- *              2) As far as it is possible without changes to the Dhrystone
- *              statistics, optimizing compilers should be prevented from
- *              removing significant statements.
- *
- *              This C version has been developed in cooperation with
- *              Rick Richardson (Tinton Falls, NJ), it incorporates many
- *              ideas from the "Version 1.1" distributed previously by
- *              him over the UNIX network Usenet.
- *              I also thank Chaim Benedelac (National Semiconductor),
- *              David Ditzel (SUN), Earl Killian and John Mashey (MIPS),
- *              Alan Smith and Rafael Saavedra-Barrera (UC at Berkeley)
- *              for their help with comments on earlier versions of the
- *              benchmark.
- *
- *  Changes:    In the initialization part, this version follows mostly
- *              Rick Richardson's version distributed via Usenet, not the
- *              version distributed earlier via floppy disk by Reinhold Weicker.
- *              As a concession to older compilers, names have been made
- *              unique within the first 8 characters.
- *              Inside the measurement loop, this version follows the
- *              version previously distributed by Reinhold Weicker.
- *
- *              At several places in the benchmark, code has been added,
- *              but within the measurement loop only in branches that 
- *              are not executed. The intention is that optimizing compilers
- *              should be prevented from moving code out of the measurement
- *              loop, or from removing code altogether. Since the statements
- *              that are executed within the measurement loop have NOT been
- *              changed, the numbers defining the "Dhrystone distribution"
- *              (distribution of statements, operand types and locality)
- *              still hold. Except for sophisticated optimizing compilers,
- *              execution times for this version should be the same as
- *              for previous versions.
- *              
- *              Since it has proven difficult to subtract the time for the
- *              measurement loop overhead in a correct way, the loop check
- *              has been made a part of the benchmark. This does have
- *              an impact - though a very minor one - on the distribution
- *              statistics which have been updated for this version.
- *
- *              All changes within the measurement loop are described
- *              and discussed in the companion paper "Rationale for
- *              Dhrystone version 2".
- *
- *              Because of the self-imposed limitation that the order and
- *              distribution of the executed statements should not be
- *              changed, there are still cases where optimizing compilers
- *              may not generate code for some statements. To a certain
- *              degree, this is unavoidable for small synthetic benchmarks.
- *              Users of the benchmark are advised to check code listings
- *              whether code is generated for all statements of Dhrystone.
- *
- *              Version 2.1 is identical to version 2.0 distributed via
- *              the UNIX network Usenet in March 1988 except that it corrects
- *              some minor deficiencies that were found by users of version 2.0.
- *              The only change within the measurement loop is that a
- *              non-executed "else" part was added to the "if" statement in
- *              Func_3, and a non-executed "else" part removed from Proc_3.
- *
- ***************************************************************************
- *
- * Defines:     The following "Defines" are possible:
- *              -DREG=register          (default: Not defined)
- *                      As an approximation to what an average C programmer
- *                      might do, the "register" storage class is applied
- *                      (if enabled by -DREG=register)
- *                      - for local variables, if they are used (dynamically)
- *                        five or more times
- *                      - for parameters if they are used (dynamically)
- *                        six or more times
- *                      Note that an optimal "register" strategy is
- *                      compiler-dependent, and that "register" declarations
- *                      do not necessarily lead to faster execution.
- *              -DNOSTRUCTASSIGN        (default: Not defined)
- *                      Define if the C compiler does not support
- *                      assignment of structures.
- *              -DNOENUMS               (default: Not defined)
- *                      Define if the C compiler does not support
- *                      enumeration types.
- *              -DTIMES                 (default)
- *              -DTIME
- *                      The "times" function of UNIX (returning process times)
- *                      or the "time" function (returning wallclock time)
- *                      is used for measurement. 
- *                      For single user machines, "time ()" is adequate. For
- *                      multi-user machines where you cannot get single-user
- *                      access, use the "times ()" function. If you have
- *                      neither, use a stopwatch in the dead of night.
- *                      "printf"s are provided marking the points "Start Timer"
- *                      and "Stop Timer". DO NOT use the UNIX "time(1)"
- *                      command, as this will measure the total time to
- *                      run this program, which will (erroneously) include
- *                      the time to allocate storage (malloc) and to perform
- *                      the initialization.
- *              -DHZ=nnn
- *                      In Berkeley UNIX, the function "times" returns process
- *                      time in 1/HZ seconds, with HZ = 60 for most systems.
- *                      CHECK YOUR SYSTEM DESCRIPTION BEFORE YOU JUST APPLY
- *                      A VALUE.
- *
- ***************************************************************************
- *
- *  Compilation model and measurement (IMPORTANT):
- *
- *  This C version of Dhrystone consists of three files:
- *  - dhry.h (this file, containing global definitions and comments)
- *  - dhry_1.c (containing the code corresponding to Ada package Pack_1)
- *  - dhry_2.c (containing the code corresponding to Ada package Pack_2)
- *
- *  The following "ground rules" apply for measurements:
- *  - Separate compilation
- *  - No procedure merging
- *  - Otherwise, compiler optimizations are allowed but should be indicated
- *  - Default results are those without register declarations
- *  See the companion paper "Rationale for Dhrystone Version 2" for a more
- *  detailed discussion of these ground rules.
- *
- *  For 16-Bit processors (e.g. 80186, 80286), times for all compilation
- *  models ("small", "medium", "large" etc.) should be given if possible,
- *  together with a definition of these models for the compiler system used.
- *
- **************************************************************************
- *
- *  Dhrystone (C version) statistics:
- *
- *  [Comment from the first distribution, updated for version 2.
- *   Note that because of language differences, the numbers are slightly
- *   different from the Ada version.]
- *
- *  The following program contains statements of a high level programming
- *  language (here: C) in a distribution considered representative:           
- *
- *    assignments                  52 (51.0 %)
- *    control statements           33 (32.4 %)
- *    procedure, function calls    17 (16.7 %)
- *
- *  103 statements are dynamically executed. The program is balanced with
- *  respect to the three aspects:                                             
- *
- *    - statement type
- *    - operand type
- *    - operand locality
- *         operand global, local, parameter, or constant.                     
- *
- *  The combination of these three aspects is balanced only approximately.    
- *
- *  1. Statement Type:                                                        
- *  -----------------             number
- *
- *     V1 = V2                     9
- *       (incl. V1 = F(..)
- *     V = Constant               12
- *     Assignment,                 7
- *       with array element
- *     Assignment,                 6
- *       with record component
- *                                --
- *                                34       34
- *
- *     X = Y +|-|"&&"|"|" Z        5
- *     X = Y +|-|"==" Constant     6
- *     X = X +|- 1                 3
- *     X = Y *|/ Z                 2
- *     X = Expression,             1
- *           two operators
- *     X = Expression,             1
- *           three operators
- *                                --
- *                                18       18
- *
- *     if ....                    14
- *       with "else"      7
- *       without "else"   7
- *           executed        3
- *           not executed    4
- *     for ...                     7  |  counted every time
- *     while ...                   4  |  the loop condition
- *     do ... while                1  |  is evaluated
- *     switch ...                  1
- *     break                       1
- *     declaration with            1
- *       initialization
- *                                --
- *                                34       34
- *
- *     P (...)  procedure call    11
- *       user procedure      10
- *       library procedure    1
- *     X = F (...)
- *             function  call      6
- *       user function        5                                         
- *       library function     1                                               
- *                                --                                          
- *                                17       17
- *                                        ---
- *                                        103
- *
- *    The average number of parameters in procedure or function calls
- *    is 1.82 (not counting the function values as implicit parameters).
- *
- *
- *  2. Operators
- *  ------------
- *                          number    approximate
- *                                    percentage
- *
- *    Arithmetic             32          50.8                                 
- *
- *       +                     21          33.3                              
- *       -                      7          11.1                              
- *       *                      3           4.8
- *       / (int div)            1           1.6
- *
- *    Comparison             27           42.8
- *
- *       ==                     9           14.3
- *       /=                     4            6.3
- *       >                      1            1.6
- *       <                      3            4.8
- *       >=                     1            1.6
- *       <=                     9           14.3
- *
- *    Logic                   4            6.3
- *
- *       && (AND-THEN)          1            1.6
- *       |  (OR)                1            1.6
- *       !  (NOT)               2            3.2
- * 
- *                           --          -----
- *                           63          100.1
- *
- *
- *  3. Operand Type (counted once per operand reference):
- *  ---------------
- *                          number    approximate
- *                                    percentage
- *
- *     Integer               175        72.3 %
- *     Character              45        18.6 %
- *     Pointer                12         5.0 %
- *     String30                6         2.5 %
- *     Array                   2         0.8 %
- *     Record                  2         0.8 %
- *                           ---       -------
- *                           242       100.0 %
- *
- *  When there is an access path leading to the final operand (e.g. a record
- *  component), only the final data type on the access path is counted.       
- *
- *
- *  4. Operand Locality:                                                      
- *  -------------------
- *                                number    approximate
- *                                          percentage
- *
- *     local variable              114        47.1 %
- *     global variable              22         9.1 %
- *     parameter                    45        18.6 %
- *        value                        23         9.5 %
- *        reference                    22         9.1 %
- *     function result               6         2.5 %
- *     constant                     55        22.7 %
- *                                 ---       -------
- *                                 242       100.0 %
- *
- *
- *  The program does not compute anything meaningful, but it is syntactically
- *  and semantically correct. All variables have a value assigned to them
- *  before they are used as a source operand.
- *
- *  There has been no explicit effort to account for the effects of a
- *  cache, or to balance the use of long or short displacements for code or
- *  data.
- *
- ***************************************************************************
- */
-
-/* Compiler and system dependent definitions: */
-
-#ifndef TIME
-#define TIMES
-#endif
-                /* Use times(2) time function unless    */
-                /* explicitly defined otherwise         */
-
-#ifdef TIMES
-#include <sys/types.h>
-#include <sys/times.h>
-                /* for "times" */
-#endif
-
-#define Mic_secs_Per_Second     1000000.0
-                /* Berkeley UNIX C returns process times in seconds/HZ */
-
-#ifdef  NOSTRUCTASSIGN
-#define structassign(d, s)      memcpy(&(d), &(s), sizeof(d))
-#else
-#define structassign(d, s)      d = s
-#endif
-
-#ifdef  NOENUM
-#define Ident_1 0
-#define Ident_2 1
-#define Ident_3 2
-#define Ident_4 3
-#define Ident_5 4
-  typedef int   Enumeration;
-#else
-  typedef       enum    {Ident_1, Ident_2, Ident_3, Ident_4, Ident_5}
-                Enumeration;
-#endif
-        /* for boolean and enumeration types in Ada, Pascal */
-
-/* General definitions: */
-
-#include <stdio.h>
-                /* for strcpy, strcmp */
-
-#define Null 0 
-                /* Value of a Null pointer */
-#define true  1
-#define false 0
-
-typedef int     One_Thirty;
-typedef int     One_Fifty;
-typedef char    Capital_Letter;
-typedef int     Boolean;
-typedef char    Str_30 [31];
-typedef int     Arr_1_Dim [50];
-typedef int     Arr_2_Dim [50] [50];
-
-typedef struct record 
-    {
-    struct record *Ptr_Comp;
-    Enumeration    Discr;
-    union {
-          struct {
-                  Enumeration Enum_Comp;
-                  int         Int_Comp;
-                  char        Str_Comp [31];
-                  } var_1;
-          struct {
-                  Enumeration E_Comp_2;
-                  char        Str_2_Comp [31];
-                  } var_2;
-          struct {
-                  char        Ch_1_Comp;
-                  char        Ch_2_Comp;
-                  } var_3;
-          } variant;
-      } Rec_Type, *Rec_Pointer;
-
-
//GO.SYSIN DD dhry.h
echo dhry_1.c 1>&2
sed >dhry_1.c <<'//GO.SYSIN DD dhry_1.c' 's/^-//'
-/*
- ****************************************************************************
- *
- *                   "DHRYSTONE" Benchmark Program
- *                   -----------------------------
- *                                                                            
- *  Version:    C, Version 2.1
- *                                                                            
- *  File:       dhry_1.c (part 2 of 3)
- *
- *  Date:       May 25, 1988
- *
- *  Author:     Reinhold P. Weicker
- *
- ****************************************************************************
- */
-
-#include "dhry.h"
-
-/* Global Variables: */
-
-Rec_Pointer     Ptr_Glob,
-                Next_Ptr_Glob;
-int             Int_Glob;
-Boolean         Bool_Glob;
-char            Ch_1_Glob,
-                Ch_2_Glob;
-int             Arr_1_Glob [50];
-int             Arr_2_Glob [50] [50];
-
-extern char     *malloc ();
-Enumeration     Func_1 ();
-  /* forward declaration necessary since Enumeration may not simply be int */
-
-#ifndef REG
-        Boolean Reg = false;
-#define REG
-        /* REG becomes defined as empty */
-        /* i.e. no register variables   */
-#else
-        Boolean Reg = true;
-#endif
-
-/* variables for time measurement: */
-
-#ifdef TIMES
-struct tms      time_info;
-extern  int     times ();
-                /* see library function "times" */
-#define Too_Small_Time 120
-                /* Measurements should last at least about 2 seconds */
-#endif
-#ifdef TIME
-extern long     time();
-                /* see library function "time"  */
-#define Too_Small_Time 2
-                /* Measurements should last at least 2 seconds */
-#endif
-
-long            Begin_Time,
-                End_Time,
-                User_Time;
-float           Microseconds,
-                Dhrystones_Per_Second;
-
-/* end of variables for time measurement */
-
-
-main ()
-/*****/
-
-  /* main program, corresponds to procedures        */
-  /* Main and Proc_0 in the Ada version             */
-{
-        One_Fifty       Int_1_Loc;
-  REG   One_Fifty       Int_2_Loc;
-        One_Fifty       Int_3_Loc;
-  REG   char            Ch_Index;
-        Enumeration     Enum_Loc;
-        Str_30          Str_1_Loc;
-        Str_30          Str_2_Loc;
-  REG   int             Run_Index;
-  REG   int             Number_Of_Runs;
-
-  /* Initializations */
-
-  Next_Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type));
-  Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type));
-
-  Ptr_Glob->Ptr_Comp                    = Next_Ptr_Glob;
-  Ptr_Glob->Discr                       = Ident_1;
-  Ptr_Glob->variant.var_1.Enum_Comp     = Ident_3;
-  Ptr_Glob->variant.var_1.Int_Comp      = 40;
-  strcpy (Ptr_Glob->variant.var_1.Str_Comp, 
-          "DHRYSTONE PROGRAM, SOME STRING");
-  strcpy (Str_1_Loc, "DHRYSTONE PROGRAM, 1'ST STRING");
-
-  Arr_2_Glob [8][7] = 10;
-        /* Was missing in published program. Without this statement,    */
-        /* Arr_2_Glob [8][7] would have an undefined value.             */
-        /* Warning: With 16-Bit processors and Number_Of_Runs > 32000,  */
-        /* overflow may occur for this array element.                   */
-
-  printf ("\n");
-  printf ("Dhrystone Benchmark, Version 2.1 (Language: C)\n");
-  printf ("\n");
-  if (Reg)
-  {
-    printf ("Program compiled with 'register' attribute\n");
-    printf ("\n");
-  }
-  else
-  {
-    printf ("Program compiled without 'register' attribute\n");
-    printf ("\n");
-  }
-  printf ("Please give the number of runs through the benchmark: ");
-  {
-    int n;
-    scanf ("%d", &n);
-    Number_Of_Runs = n;
-  }
-  printf ("\n");
-
-  printf ("Execution starts, %d runs through Dhrystone\n", Number_Of_Runs);
-
-  /***************/
-  /* Start timer */
-  /***************/
- 
-#ifdef TIMES
-  times (&time_info);
-  Begin_Time = (long) time_info.tms_utime;
-#endif
-#ifdef TIME
-  Begin_Time = time ( (long *) 0);
-#endif
-
-  for (Run_Index = 1; Run_Index <= Number_Of_Runs; ++Run_Index)
-  {
-
-    Proc_5();
-    Proc_4();
-      /* Ch_1_Glob == 'A', Ch_2_Glob == 'B', Bool_Glob == true */
-    Int_1_Loc = 2;
-    Int_2_Loc = 3;
-    strcpy (Str_2_Loc, "DHRYSTONE PROGRAM, 2'ND STRING");
-    Enum_Loc = Ident_2;
-    Bool_Glob = ! Func_2 (Str_1_Loc, Str_2_Loc);
-      /* Bool_Glob == 1 */
-    while (Int_1_Loc < Int_2_Loc)  /* loop body executed once */
-    {
-      Int_3_Loc = 5 * Int_1_Loc - Int_2_Loc;
-        /* Int_3_Loc == 7 */
-      Proc_7 (Int_1_Loc, Int_2_Loc, &Int_3_Loc);
-        /* Int_3_Loc == 7 */
-      Int_1_Loc += 1;
-    } /* while */
-      /* Int_1_Loc == 3, Int_2_Loc == 3, Int_3_Loc == 7 */
-    Proc_8 (Arr_1_Glob, Arr_2_Glob, Int_1_Loc, Int_3_Loc);
-      /* Int_Glob == 5 */
-    Proc_1 (Ptr_Glob);
-    for (Ch_Index = 'A'; Ch_Index <= Ch_2_Glob; ++Ch_Index)
-                             /* loop body executed twice */
-    {
-      if (Enum_Loc == Func_1 (Ch_Index, 'C'))
-          /* then, not executed */
-        {
-        Proc_6 (Ident_1, &Enum_Loc);
-        strcpy (Str_2_Loc, "DHRYSTONE PROGRAM, 3'RD STRING");
-        Int_2_Loc = Run_Index;
-        Int_Glob = Run_Index;
-        }
-    }
-      /* Int_1_Loc == 3, Int_2_Loc == 3, Int_3_Loc == 7 */
-    Int_2_Loc = Int_2_Loc * Int_1_Loc;
-    Int_1_Loc = Int_2_Loc / Int_3_Loc;
-    Int_2_Loc = 7 * (Int_2_Loc - Int_3_Loc) - Int_1_Loc;
-      /* Int_1_Loc == 1, Int_2_Loc == 13, Int_3_Loc == 7 */
-    Proc_2 (&Int_1_Loc);
-      /* Int_1_Loc == 5 */
-
-  } /* loop "for Run_Index" */
-
-  /**************/
-  /* Stop timer */
-  /**************/
-  
-#ifdef TIMES
-  times (&time_info);
-  End_Time = (long) time_info.tms_utime;
-#endif
-#ifdef TIME
-  End_Time = time ( (long *) 0);
-#endif
-
-  printf ("Execution ends\n");
-  printf ("\n");
-  printf ("Final values of the variables used in the benchmark:\n");
-  printf ("\n");
-  printf ("Int_Glob:            %d\n", Int_Glob);
-  printf ("        should be:   %d\n", 5);
-  printf ("Bool_Glob:           %d\n", Bool_Glob);
-  printf ("        should be:   %d\n", 1);
-  printf ("Ch_1_Glob:           %c\n", Ch_1_Glob);
-  printf ("        should be:   %c\n", 'A');
-  printf ("Ch_2_Glob:           %c\n", Ch_2_Glob);
-  printf ("        should be:   %c\n", 'B');
-  printf ("Arr_1_Glob[8]:       %d\n", Arr_1_Glob[8]);
-  printf ("        should be:   %d\n", 7);
-  printf ("Arr_2_Glob[8][7]:    %d\n", Arr_2_Glob[8][7]);
-  printf ("        should be:   Number_Of_Runs + 10\n");
-  printf ("Ptr_Glob->\n");
-  printf ("  Ptr_Comp:          %d\n", (int) Ptr_Glob->Ptr_Comp);
-  printf ("        should be:   (implementation-dependent)\n");
-  printf ("  Discr:             %d\n", Ptr_Glob->Discr);
-  printf ("        should be:   %d\n", 0);
-  printf ("  Enum_Comp:         %d\n", Ptr_Glob->variant.var_1.Enum_Comp);
-  printf ("        should be:   %d\n", 2);
-  printf ("  Int_Comp:          %d\n", Ptr_Glob->variant.var_1.Int_Comp);
-  printf ("        should be:   %d\n", 17);
-  printf ("  Str_Comp:          %s\n", Ptr_Glob->variant.var_1.Str_Comp);
-  printf ("        should be:   DHRYSTONE PROGRAM, SOME STRING\n");
-  printf ("Next_Ptr_Glob->\n");
-  printf ("  Ptr_Comp:          %d\n", (int) Next_Ptr_Glob->Ptr_Comp);
-  printf ("        should be:   (implementation-dependent), same as above\n");
-  printf ("  Discr:             %d\n", Next_Ptr_Glob->Discr);
-  printf ("        should be:   %d\n", 0);
-  printf ("  Enum_Comp:         %d\n", Next_Ptr_Glob->variant.var_1.Enum_Comp);
-  printf ("        should be:   %d\n", 1);
-  printf ("  Int_Comp:          %d\n", Next_Ptr_Glob->variant.var_1.Int_Comp);
-  printf ("        should be:   %d\n", 18);
-  printf ("  Str_Comp:          %s\n",
-                                Next_Ptr_Glob->variant.var_1.Str_Comp);
-  printf ("        should be:   DHRYSTONE PROGRAM, SOME STRING\n");
-  printf ("Int_1_Loc:           %d\n", Int_1_Loc);
-  printf ("        should be:   %d\n", 5);
-  printf ("Int_2_Loc:           %d\n", Int_2_Loc);
-  printf ("        should be:   %d\n", 13);
-  printf ("Int_3_Loc:           %d\n", Int_3_Loc);
-  printf ("        should be:   %d\n", 7);
-  printf ("Enum_Loc:            %d\n", Enum_Loc);
-  printf ("        should be:   %d\n", 1);
-  printf ("Str_1_Loc:           %s\n", Str_1_Loc);
-  printf ("        should be:   DHRYSTONE PROGRAM, 1'ST STRING\n");
-  printf ("Str_2_Loc:           %s\n", Str_2_Loc);
-  printf ("        should be:   DHRYSTONE PROGRAM, 2'ND STRING\n");
-  printf ("\n");
-
-  User_Time = End_Time - Begin_Time;
-
-  if (User_Time < Too_Small_Time)
-  {
-    printf ("Measured time too small to obtain meaningful results\n");
-    printf ("Please increase number of runs\n");
-    printf ("\n");
-  }
-  else
-  {
-#ifdef TIME
-    Microseconds = (float) User_Time * Mic_secs_Per_Second 
-                        / (float) Number_Of_Runs;
-    Dhrystones_Per_Second = (float) Number_Of_Runs / (float) User_Time;
-#else
-    Microseconds = (float) User_Time * Mic_secs_Per_Second 
-                        / ((float) HZ * ((float) Number_Of_Runs));
-    Dhrystones_Per_Second = ((float) HZ * (float) Number_Of_Runs)
-                        / (float) User_Time;
-#endif
-    printf ("Microseconds for one run through Dhrystone: ");
-    printf ("%6.1f \n", Microseconds);
-    printf ("Dhrystones per Second:                      ");
-    printf ("%6.1f \n", Dhrystones_Per_Second);
-    printf ("\n");
-  }
-  
-}
-
-
-Proc_1 (Ptr_Val_Par)
-/******************/
-
-REG Rec_Pointer Ptr_Val_Par;
-    /* executed once */
-{
-  REG Rec_Pointer Next_Record = Ptr_Val_Par->Ptr_Comp;  
-                                        /* == Ptr_Glob_Next */
-  /* Local variable, initialized with Ptr_Val_Par->Ptr_Comp,    */
-  /* corresponds to "rename" in Ada, "with" in Pascal           */
-  
-  structassign (*Ptr_Val_Par->Ptr_Comp, *Ptr_Glob); 
-  Ptr_Val_Par->variant.var_1.Int_Comp = 5;
-  Next_Record->variant.var_1.Int_Comp 
-        = Ptr_Val_Par->variant.var_1.Int_Comp;
-  Next_Record->Ptr_Comp = Ptr_Val_Par->Ptr_Comp;
-  Proc_3 (&Next_Record->Ptr_Comp);
-    /* Ptr_Val_Par->Ptr_Comp->Ptr_Comp 
-                        == Ptr_Glob->Ptr_Comp */
-  if (Next_Record->Discr == Ident_1)
-    /* then, executed */
-  {
-    Next_Record->variant.var_1.Int_Comp = 6;
-    Proc_6 (Ptr_Val_Par->variant.var_1.Enum_Comp, 
-           &Next_Record->variant.var_1.Enum_Comp);
-    Next_Record->Ptr_Comp = Ptr_Glob->Ptr_Comp;
-    Proc_7 (Next_Record->variant.var_1.Int_Comp, 10, 
-           &Next_Record->variant.var_1.Int_Comp);
-  }
-  else /* not executed */
-    structassign (*Ptr_Val_Par, *Ptr_Val_Par->Ptr_Comp);
-} /* Proc_1 */
-
-
-Proc_2 (Int_Par_Ref)
-/******************/
-    /* executed once */
-    /* *Int_Par_Ref == 1, becomes 4 */
-
-One_Fifty   *Int_Par_Ref;
-{
-  One_Fifty  Int_Loc;  
-  Enumeration   Enum_Loc;
-
-  Int_Loc = *Int_Par_Ref + 10;
-  do /* executed once */
-    if (Ch_1_Glob == 'A')
-      /* then, executed */
-    {
-      Int_Loc -= 1;
-      *Int_Par_Ref = Int_Loc - Int_Glob;
-      Enum_Loc = Ident_1;
-    } /* if */
-  while (Enum_Loc != Ident_1); /* true */
-} /* Proc_2 */
-
-
-Proc_3 (Ptr_Ref_Par)
-/******************/
-    /* executed once */
-    /* Ptr_Ref_Par becomes Ptr_Glob */
-
-Rec_Pointer *Ptr_Ref_Par;
-
-{
-  if (Ptr_Glob != Null)
-    /* then, executed */
-    *Ptr_Ref_Par = Ptr_Glob->Ptr_Comp;
-  Proc_7 (10, Int_Glob, &Ptr_Glob->variant.var_1.Int_Comp);
-} /* Proc_3 */
-
-
-Proc_4 () /* without parameters */
-/*******/
-    /* executed once */
-{
-  Boolean Bool_Loc;
-
-  Bool_Loc = Ch_1_Glob == 'A';
-  Bool_Glob = Bool_Loc | Bool_Glob;
-  Ch_2_Glob = 'B';
-} /* Proc_4 */
-
-
-Proc_5 () /* without parameters */
-/*******/
-    /* executed once */
-{
-  Ch_1_Glob = 'A';
-  Bool_Glob = false;
-} /* Proc_5 */
-
-
-        /* Procedure for the assignment of structures,          */
-        /* if the C compiler doesn't support this feature       */
-#ifdef  NOSTRUCTASSIGN
-memcpy (d, s, l)
-register char   *d;
-register char   *s;
-register int    l;
-{
-        while (l--) *d++ = *s++;
-}
-#endif
-
-
//GO.SYSIN DD dhry_1.c
echo dhry_2.c 1>&2
sed >dhry_2.c <<'//GO.SYSIN DD dhry_2.c' 's/^-//'
-/*
- ****************************************************************************
- *
- *                   "DHRYSTONE" Benchmark Program
- *                   -----------------------------
- *                                                                            
- *  Version:    C, Version 2.1
- *                                                                            
- *  File:       dhry_2.c (part 3 of 3)
- *
- *  Date:       May 25, 1988
- *
- *  Author:     Reinhold P. Weicker
- *
- ****************************************************************************
- */
-
-#include "dhry.h"
-
-#ifndef REG
-#define REG
-        /* REG becomes defined as empty */
-        /* i.e. no register variables   */
-#endif
-
-extern  int     Int_Glob;
-extern  char    Ch_1_Glob;
-
-
-Proc_6 (Enum_Val_Par, Enum_Ref_Par)
-/*********************************/
-    /* executed once */
-    /* Enum_Val_Par == Ident_3, Enum_Ref_Par becomes Ident_2 */
-
-Enumeration  Enum_Val_Par;
-Enumeration *Enum_Ref_Par;
-{
-  *Enum_Ref_Par = Enum_Val_Par;
-  if (! Func_3 (Enum_Val_Par))
-    /* then, not executed */
-    *Enum_Ref_Par = Ident_4;
-  switch (Enum_Val_Par)
-  {
-    case Ident_1: 
-      *Enum_Ref_Par = Ident_1;
-      break;
-    case Ident_2: 
-      if (Int_Glob > 100)
-        /* then */
-      *Enum_Ref_Par = Ident_1;
-      else *Enum_Ref_Par = Ident_4;
-      break;
-    case Ident_3: /* executed */
-      *Enum_Ref_Par = Ident_2;
-      break;
-    case Ident_4: break;
-    case Ident_5: 
-      *Enum_Ref_Par = Ident_3;
-      break;
-  } /* switch */
-} /* Proc_6 */
-
-
-Proc_7 (Int_1_Par_Val, Int_2_Par_Val, Int_Par_Ref)
-/**********************************************/
-    /* executed three times                                      */ 
-    /* first call:      Int_1_Par_Val == 2, Int_2_Par_Val == 3,  */
-    /*                  Int_Par_Ref becomes 7                    */
-    /* second call:     Int_1_Par_Val == 10, Int_2_Par_Val == 5, */
-    /*                  Int_Par_Ref becomes 17                   */
-    /* third call:      Int_1_Par_Val == 6, Int_2_Par_Val == 10, */
-    /*                  Int_Par_Ref becomes 18                   */
-One_Fifty       Int_1_Par_Val;
-One_Fifty       Int_2_Par_Val;
-One_Fifty      *Int_Par_Ref;
-{
-  One_Fifty Int_Loc;
-
-  Int_Loc = Int_1_Par_Val + 2;
-  *Int_Par_Ref = Int_2_Par_Val + Int_Loc;
-} /* Proc_7 */
-
-
-Proc_8 (Arr_1_Par_Ref, Arr_2_Par_Ref, Int_1_Par_Val, Int_2_Par_Val)
-/*********************************************************************/
-    /* executed once      */
-    /* Int_Par_Val_1 == 3 */
-    /* Int_Par_Val_2 == 7 */
-Arr_1_Dim       Arr_1_Par_Ref;
-Arr_2_Dim       Arr_2_Par_Ref;
-int             Int_1_Par_Val;
-int             Int_2_Par_Val;
-{
-  REG One_Fifty Int_Index;
-  REG One_Fifty Int_Loc;
-
-  Int_Loc = Int_1_Par_Val + 5;
-  Arr_1_Par_Ref [Int_Loc] = Int_2_Par_Val;
-  Arr_1_Par_Ref [Int_Loc+1] = Arr_1_Par_Ref [Int_Loc];
-  Arr_1_Par_Ref [Int_Loc+30] = Int_Loc;
-  for (Int_Index = Int_Loc; Int_Index <= Int_Loc+1; ++Int_Index)
-    Arr_2_Par_Ref [Int_Loc] [Int_Index] = Int_Loc;
-  Arr_2_Par_Ref [Int_Loc] [Int_Loc-1] += 1;
-  Arr_2_Par_Ref [Int_Loc+20] [Int_Loc] = Arr_1_Par_Ref [Int_Loc];
-  Int_Glob = 5;
-} /* Proc_8 */
-
-
-Enumeration Func_1 (Ch_1_Par_Val, Ch_2_Par_Val)
-/*************************************************/
-    /* executed three times                                         */
-    /* first call:      Ch_1_Par_Val == 'H', Ch_2_Par_Val == 'R'    */
-    /* second call:     Ch_1_Par_Val == 'A', Ch_2_Par_Val == 'C'    */
-    /* third call:      Ch_1_Par_Val == 'B', Ch_2_Par_Val == 'C'    */
-
-Capital_Letter   Ch_1_Par_Val;
-Capital_Letter   Ch_2_Par_Val;
-{
-  Capital_Letter        Ch_1_Loc;
-  Capital_Letter        Ch_2_Loc;
-
-  Ch_1_Loc = Ch_1_Par_Val;
-  Ch_2_Loc = Ch_1_Loc;
-  if (Ch_2_Loc != Ch_2_Par_Val)
-    /* then, executed */
-    return (Ident_1);
-  else  /* not executed */
-  {
-    Ch_1_Glob = Ch_1_Loc;
-    return (Ident_2);
-   }
-} /* Func_1 */
-
-
-Boolean Func_2 (Str_1_Par_Ref, Str_2_Par_Ref)
-/*************************************************/
-    /* executed once */
-    /* Str_1_Par_Ref == "DHRYSTONE PROGRAM, 1'ST STRING" */
-    /* Str_2_Par_Ref == "DHRYSTONE PROGRAM, 2'ND STRING" */
-
-Str_30  Str_1_Par_Ref;
-Str_30  Str_2_Par_Ref;
-{
-  REG One_Thirty        Int_Loc;
-      Capital_Letter    Ch_Loc;
-
-  Int_Loc = 2;
-  while (Int_Loc <= 2) /* loop body executed once */
-    if (Func_1 (Str_1_Par_Ref[Int_Loc],
-                Str_2_Par_Ref[Int_Loc+1]) == Ident_1)
-      /* then, executed */
-    {
-      Ch_Loc = 'A';
-      Int_Loc += 1;
-    } /* if, while */
-  if (Ch_Loc >= 'W' && Ch_Loc < 'Z')
-    /* then, not executed */
-    Int_Loc = 7;
-  if (Ch_Loc == 'R')
-    /* then, not executed */
-    return (true);
-  else /* executed */
-  {
-    if (strcmp (Str_1_Par_Ref, Str_2_Par_Ref) > 0)
-      /* then, not executed */
-    {
-      Int_Loc += 7;
-      Int_Glob = Int_Loc;
-      return (true);
-    }
-    else /* executed */
-      return (false);
-  } /* if Ch_Loc */
-} /* Func_2 */
-
-
-Boolean Func_3 (Enum_Par_Val)
-/***************************/
-    /* executed once        */
-    /* Enum_Par_Val == Ident_3 */
-Enumeration Enum_Par_Val;
-{
-  Enumeration Enum_Loc;
-
-  Enum_Loc = Enum_Par_Val;
-  if (Enum_Loc == Ident_3)
-    /* then, executed */
-    return (true);
-  else /* not executed */
-    return (false);
-} /* Func_3 */
-
//GO.SYSIN DD dhry_2.c
echo dhry_c.dif 1>&2
sed >dhry_c.dif <<'//GO.SYSIN DD dhry_c.dif' 's/^-//'
-7c7
-<  *  Version:    C, Version 2.1
----
->  *  Version:    C, Version 2.0
-9c9
-<  *  File:       dhry.h (part 1 of 3)
----
->  *  File:       dhry_global.h (part 1 of 3)
-11c11
-<  *  Date:       May 25, 1988
----
->  *  Date:       March 3, 1988
-30c30
-<  *              In addition, Berkeley UNIX system calls "times ()" or "time ()"
----
->  *              In addition, UNIX system calls "times ()" or "time ()"
-44c44
-<  *      Please send results to Rick Richardson and/or Reinhold Weicker.
----
->  *      Please send results to Reinhold Weicker and/or Rick Richardson.
-59c59
-<  *  History:    This version C/2.1 has been made for two reasons:
----
->  *  History:    This version C/2.0 has been made for two reasons:
-123,129d122
-<  *              Version 2.1 is identical to version 2.0 distributed via
-<  *              the UNIX network Usenet in March 1988 except that it corrects
-<  *              some minor deficiencies that were found by users of version 2.0.
-<  *              The only change within the measurement loop is that a
-<  *              non-executed "else" part was added to the "if" statement in
-<  *              Func_3, and a non-executed "else" part removed from Proc_3.
-<  *
-165,167c158,160
-<  *              -DHZ=nnn
-<  *                      In Berkeley UNIX, the function "times" returns process
-<  *                      time in 1/HZ seconds, with HZ = 60 for most systems.
----
->  *              -DHZ=nnn                (default: 60)
->  *                      The function "times" returns process times in
->  *                      1/HZ seconds, with HZ = 60 for most systems.
-169c162
-<  *                      A VALUE.
----
->  *                      THE DEFAULT VALUE.
-176,178c169,171
-<  *  - dhry.h (this file, containing global definitions and comments)
-<  *  - dhry_1.c (containing the code corresponding to Ada package Pack_1)
-<  *  - dhry_2.c (containing the code corresponding to Ada package Pack_2)
----
->  *  - dhry_global.h (this file, containing global definitions and comments)
->  *  - dhry_pack_1.c (containing the code corresponding to Ada package Pack_1)
->  *  - dhry_pack_2.c (containing the code corresponding to Ada package Pack_2)
-350a344
-> #ifndef TIMES
-353,354c347,354
-<                 /* Use times(2) time function unless    */
-<                 /* explicitly defined otherwise         */
----
-> #endif
->                 /* Use "times" function for measurement */
->                 /* unless explicitly defined otherwise  */
-> #ifndef HZ
-> #define HZ      60
-> #endif
->                 /* Use HZ = 60 for "times" function     */
->                 /* unless explicitly defined otherwise  */
-363c363
-<                 /* Berkeley UNIX C returns process times in seconds/HZ */
----
->                 /* UNIX C returns process times in seconds/HZ */
-7c7
-<  *  Version:    C, Version 2.1
----
->  *  Version:    C, Version 2.0
-9c9
-<  *  File:       dhry_1.c (part 2 of 3)
----
->  *  File:       dhry_pack_1.c (part 2 of 3)
-11c11
-<  *  Date:       May 25, 1988
----
->  *  Date:       March 3, 1988
-18c18
-< #include "dhry.h"
----
-> #include "dhry_global.h"
-50,51d49
-< #define Too_Small_Time 120
-<                 /* Measurements should last at least about 2 seconds */
-55a54,55
-> #endif
-> 
-58d57
-< #endif
-73a73
-> 
-84a85
-> 
-99,100c100,102
-<         /* Was missing in published program. Without this statement,    */
-<         /* Arr_2_Glob [8][7] would have an undefined value.             */
----
->         /* Was missing in published program. Without this               */
->         /* initialization, Arr_2_Glob [8][7] would have an              */
->         /* undefined value.                                             */
-105c107
-<   printf ("Dhrystone Benchmark, Version 2.1 (Language: C)\n");
----
->   printf ("Dhrystone Benchmark, Version 2.0 (Language: C)\n");
-281c283
-< /******************/
----
-> /**********************/
-338c340
-< /******************/
----
-> /**********************/
-347a350,351
->   else /* not executed */
->     Int_Glob = 100;
-349a354
-> 
-7c7
-<  *  Version:    C, Version 2.1
----
->  *  Version:    C, Version 2.0
-9c9
-<  *  File:       dhry_2.c (part 3 of 3)
----
->  *  File:       dhry_pack_2.c (part 3 of 3)
-11c11
-<  *  Date:       May 25, 1988
----
->  *  Date:       March 3, 1988
-18c18
-< #include "dhry.h"
----
-> #include "dhry_global.h"
-189,190d188
-<   else /* not executed */
-<     return (false);
//GO.SYSIN DD dhry_c.dif
echo submit.frm 1>&2
sed >submit.frm <<'//GO.SYSIN DD submit.frm' 's/^-//'
-DHRYSTONE 2.1 BENCHMARK REPORTING FORM
-MANUF:
-MODEL:
-PROC:
-CLOCK:
-OS:
-OVERSION:
-COMPILER:
-CVERSION:
-OPTIONS:
-NOREG:
-REG:
-NOTES:
-DATE:
-SUBMITTER:
-CODESIZE:
-MAILTO: uunet!pcrat!dry2
//GO.SYSIN DD submit.frm