| blob | 4cec46c5f77705ea9c88ec7a9fda6ac4c39b126d |
1 # to unbundle, sh this file (in an empty directory)
2 echo RATIONALE 1>&2
3 sed >RATIONALE <<'//GO.SYSIN DD RATIONALE' 's/^-//'
4 -
5 -
6 - Dhrystone Benchmark: Rationale for Version 2 and Measurement Rules
7 -
8 - [published in SIGPLAN Notices 23,8 (Aug. 1988), 49-62]
9 -
10 -
11 - Reinhold P. Weicker
12 - Siemens AG, E STE 35
13 - [now: Siemens AG, AUT E 51]
14 - Postfach 3220
15 - D-8520 Erlangen
16 - Germany (West)
17 -
18 -
19 -
20 -
21 -1. Why a Version 2 of Dhrystone?
22 -
23 -The Dhrystone benchmark program [1] has become a popular benchmark for
24 -CPU/compiler performance measurement, in particular in the area of
25 -minicomputers, workstations, PC's and microprocesors. It apparently satisfies
26 -a need for an easy-to-use integer benchmark; it gives a first performance
27 -indication which is more meaningful than MIPS numbers which, in their literal
28 -meaning (million instructions per second), cannot be used across different
29 -instruction sets (e.g. RISC vs. CISC). With the increasing use of the
30 -benchmark, it seems necessary to reconsider the benchmark and to check whether
31 -it can still fulfill this function. Version 2 of Dhrystone is the result of
32 -such a re-evaluation, it has been made for two reasons:
33 -
34 -o Dhrystone has been published in Ada [1], and Versions in Ada, Pascal and C
35 - have been distributed by Reinhold Weicker via floppy disk. However, the
36 - version that was used most often for benchmarking has been the version made
37 - by Rick Richardson by another translation from the Ada version into the C
38 - programming language, this has been the version distributed via the UNIX
39 - network Usenet [2].
40 -
41 - There is an obvious need for a common C version of Dhrystone, since C is at
42 - present the most popular system programming language for the class of
43 - systems (microcomputers, minicomputers, workstations) where Dhrystone is
44 - used most. There should be, as far as possible, only one C version of
45 - Dhrystone such that results can be compared without restrictions. In the
46 - past, the C versions distributed by Rick Richardson (Version 1.1) and by
47 - Reinhold Weicker had small (though not significant) differences.
48 -
49 - Together with the new C version, the Ada and Pascal versions have been
50 - updated as well.
51 -
52 -o As far as it is possible without changes to the Dhrystone statistics,
53 - optimizing compilers should be prevented from removing significant
54 - statements. It has turned out in the past that optimizing compilers
55 - suppressed code generation for too many statements (by "dead code removal"
56 - or "dead variable elimination"). This has lead to the danger that
57 - benchmarking results obtained by a naive application of Dhrystone - without
58 - inspection of the code that was generated - could become meaningless.
59 -
60 -The overall policiy for version 2 has been that the distribution of
61 -statements, operand types and operand locality described in [1] should remain
62 -unchanged as much as possible. (Very few changes were necessary; their impact
63 -should be negligible.) Also, the order of statements should remain unchanged.
64 -Although I am aware of some critical remarks on the benchmark - I agree with
65 -several of them - and know some suggestions for improvement, I didn't want to
66 -change the benchmark into something different from what has become known as
67 -"Dhrystone"; the confusion generated by such a change would probably outweight
68 -the benefits. If I were to write a new benchmark program, I wouldn't give it
69 -the name "Dhrystone" since this denotes the program published in [1].
70 -However, I do recognize the need for a larger number of representative
71 -programs that can be used as benchmarks; users should always be encouraged to
72 -use more than just one benchmark.
73 -
74 -The new versions (version 2.1 for C, Pascal and Ada) will be distributed as
75 -widely as possible. (Version 2.1 differs from version 2.0 distributed via the
76 -UNIX Network Usenet in March 1988 only in a few corrections for minor
77 -deficiencies found by users of version 2.0.) Readers who want to use the
78 -benchmark for their own measurements can obtain a copy in machine-readable
79 -form on floppy disk (MS-DOS or XENIX format) from the author.
80 -
81 -
82 -2. Overall Characteristics of Version 2
83 -
84 -In general, version 2 follows - in the parts that are significant for
85 -performance measurement, i.e. within the measurement loop - the published
86 -(Ada) version and the C versions previously distributed. Where the versions
87 -distributed by Rick Richardson [2] and Reinhold Weicker have been different,
88 -it follows the version distributed by Reinhold Weicker. (However, the
89 -differences have been so small that their impact on execution time in all
90 -likelihood has been negligible.) The initialization and UNIX instrumentation
91 -part - which had been omitted in [1] - follows mostly the ideas of Rick
92 -Richardson [2]. However, any changes in the initialization part and in the
93 -printing of the result have no impact on performance measurement since they
94 -are outside the measaurement loop. As a concession to older compilers, names
95 -have been made unique within the first 8 characters for the C version.
96 -
97 -The original publication of Dhrystone did not contain any statements for time
98 -measurement since they are necessarily system-dependent. However, it turned
99 -out that it is not enough just to inclose the main procedure of Dhrystone in a
100 -loop and to measure the execution time. If the variables that are computed
101 -are not used somehow, there is the danger that the compiler considers them as
102 -"dead variables" and suppresses code generation for a part of the statements.
103 -Therefore in version 2 all variables of "main" are printed at the end of the
104 -program. This also permits some plausibility control for correct execution of
105 -the benchmark.
106 -
107 -At several places in the benchmark, code has been added, but only in branches
108 -that are not executed. The intention is that optimizing compilers should be
109 -prevented from moving code out of the measurement loop, or from removing code
110 -altogether. Statements that are executed have been changed in very few places
111 -only. In these cases, only the role of some operands has been changed, and it
112 -was made sure that the numbers defining the "Dhrystone distribution"
113 -(distribution of statements, operand types and locality) still hold as much as
114 -possible. Except for sophisticated optimizing compilers, execution times for
115 -version 2.1 should be the same as for previous versions.
116 -
117 -Because of the self-imposed limitation that the order and distribution of the
118 -executed statements should not be changed, there are still cases where
119 -optimizing compilers may not generate code for some statements. To a certain
120 -degree, this is unavoidable for small synthetic benchmarks. Users of the
121 -benchmark are advised to check code listings whether code is generated for all
122 -statements of Dhrystone.
123 -
124 -Contrary to the suggestion in the published paper and its realization in the
125 -versions previously distributed, no attempt has been made to subtract the time
126 -for the measurement loop overhead. (This calculation has proven difficult to
127 -implement in a correct way, and its omission makes the program simpler.)
128 -However, since the loop check is now part of the benchmark, this does have an
129 -impact - though a very minor one - on the distribution statistics which have
130 -been updated for this version.
131 -
132 -
133 -3. Discussion of Individual Changes
134 -
135 -In this section, all changes are described that affect the measurement loop
136 -and that are not just renamings of variables. All remarks refer to the C
137 -version; the other language versions have been updated similarly.
138 -
139 -In addition to adding the measurement loop and the printout statements,
140 -changes have been made at the following places:
141 -
142 -o In procedure "main", three statements have been added in the non-executed
143 - "then" part of the statement
144 -
145 - if (Enum_Loc == Func_1 (Ch_Index, 'C'))
146 -
147 - they are
148 -
149 - strcpy (Str_2_Loc, "DHRYSTONE PROGRAM, 3'RD STRING");
150 - Int_2_Loc = Run_Index;
151 - Int_Glob = Run_Index;
152 -
153 - The string assignment prevents movement of the preceding assignment to
154 - Str_2_Loc (5'th statement of "main") out of the measurement loop (This
155 - probably will not happen for the C version, but it did happen with another
156 - language and compiler.) The assignment to Int_2_Loc prevents value
157 - propagation for Int_2_Loc, and the assignment to Int_Glob makes the value of
158 - Int_Glob possibly dependent from the value of Run_Index.
159 -
160 -o In the three arithmetic computations at the end of the measurement loop in
161 - "main ", the role of some variables has been exchanged, to prevent the
162 - division from just cancelling out the multiplication as it was in [1]. A
163 - very smart compiler might have recognized this and suppressed code
164 - generation for the division.
165 -
166 -o For Proc_2, no code has been changed, but the values of the actual parameter
167 - have changed due to changes in "main".
168 -
169 -o In Proc_4, the second assignment has been changed from
170 -
171 - Bool_Loc = Bool_Loc | Bool_Glob;
172 -
173 - to
174 -
175 - Bool_Glob = Bool_Loc | Bool_Glob;
176 -
177 - It now assigns a value to a global variable instead of a local variable
178 - (Bool_Loc); Bool_Loc would be a "dead variable" which is not used
179 - afterwards.
180 -
181 -o In Func_1, the statement
182 -
183 - Ch_1_Glob = Ch_1_Loc;
184 -
185 - was added in the non-executed "else" part of the "if" statement, to prevent
186 - the suppression of code generation for the assignment to Ch_1_Loc.
187 -
188 -o In Func_2, the second character comparison statement has been changed to
189 -
190 - if (Ch_Loc == 'R')
191 -
192 - ('R' instead of 'X') because a comparison with 'X' is implied in the
193 - preceding "if" statement.
194 -
195 - Also in Func_2, the statement
196 -
197 - Int_Glob = Int_Loc;
198 -
199 - has been added in the non-executed part of the last "if" statement, in order
200 - to prevent Int_Loc from becoming a dead variable.
201 -
202 -o In Func_3, a non-executed "else" part has been added to the "if" statement.
203 - While the program would not be incorrect without this "else" part, it is
204 - considered bad programming practice if a function can be left without a
205 - return value.
206 -
207 - To compensate for this change, the (non-executed) "else" part in the "if"
208 - statement of Proc_3 was removed.
209 -
210 -The distribution statistics have been changed only by the addition of the
211 -measurement loop iteration (1 additional statement, 4 additional local integer
212 -operands) and by the change in Proc_4 (one operand changed from local to
213 -global). The distribution statistics in the comment headers have been updated
214 -accordingly.
215 -
216 -
217 -4. String Operations
218 -
219 -The string operations (string assignment and string comparison) have not been
220 -changed, to keep the program consistent with the original version.
221 -
222 -There has been some concern that the string operations are over-represented in
223 -the program, and that execution time is dominated by these operations. This
224 -was true in particular when optimizing compilers removed too much code in the
225 -main part of the program, this should have been mitigated in version 2.
226 -
227 -It should be noted that this is a language-dependent issue: Dhrystone was
228 -first published in Ada, and with Ada or Pascal semantics, the time spent in
229 -the string operations is, at least in all implementations known to me,
230 -considerably smaller. In Ada and Pascal, assignment and comparison of strings
231 -are operators defined in the language, and the upper bounds of the strings
232 -occuring in Dhrystone are part of the type information known at compilation
233 -time. The compilers can therefore generate efficient inline code. In C,
234 -string assignemt and comparisons are not part of the language, so the string
235 -operations must be expressed in terms of the C library functions "strcpy" and
236 -"strcmp". (ANSI C allows an implementation to use inline code for these
237 -functions.) In addition to the overhead caused by additional function calls,
238 -these functions are defined for null-terminated strings where the length of
239 -the strings is not known at compilation time; the function has to check every
240 -byte for the termination condition (the null byte).
241 -
242 -Obviously, a C library which includes efficiently coded "strcpy" and "strcmp"
243 -functions helps to obtain good Dhrystone results. However, I don't think that
244 -this is unfair since string functions do occur quite frequently in real
245 -programs (editors, command interpreters, etc.). If the strings functions are
246 -implemented efficiently, this helps real programs as well as benchmark
247 -programs.
248 -
249 -I admit that the string comparison in Dhrystone terminates later (after
250 -scanning 20 characters) than most string comparisons in real programs. For
251 -consistency with the original benchmark, I didn't change the program despite
252 -this weakness.
253 -
254 -
255 -5. Intended Use of Dhrystone
256 -
257 -When Dhrystone is used, the following "ground rules" apply:
258 -
259 -o Separate compilation (Ada and C versions)
260 -
261 - As mentioned in [1], Dhrystone was written to reflect actual programming
262 - practice in systems programming. The division into several compilation
263 - units (5 in the Ada version, 2 in the C version) is intended, as is the
264 - distribution of inter-module and intra-module subprogram calls. Although on
265 - many systems there will be no difference in execution time to a Dhrystone
266 - version where all compilation units are merged into one file, the rule is
267 - that separate compilation should be used. The intention is that real
268 - programming practice, where programs consist of several independently
269 - compiled units, should be reflected. This also has implies that the
270 - compiler, while compiling one unit, has no information about the use of
271 - variables, register allocation etc. occuring in other compilation units.
272 - Although in real life compilation units will probably be larger, the
273 - intention is that these effects of separate compilation are modeled in
274 - Dhrystone.
275 -
276 - A few language systems have post-linkage optimization available (e.g., final
277 - register allocation is performed after linkage). This is a borderline case:
278 - Post-linkage optimization involves additional program preparation time
279 - (although not as much as compilation in one unit) which may prevent its
280 - general use in practical programming. I think that since it defeats the
281 - intentions given above, it should not be used for Dhrystone.
282 -
283 - Unfortunately, ISO/ANSI Pascal does not contain language features for
284 - separate compilation. Although most commercial Pascal compilers provide
285 - separate compilation in some way, we cannot use it for Dhrystone since such
286 - a version would not be portable. Therefore, no attempt has been made to
287 - provide a Pascal version with several compilation units.
288 -
289 -o No procedure merging
290 -
291 - Although Dhrystone contains some very short procedures where execution would
292 - benefit from procedure merging (inlining, macro expansion of procedures),
293 - procedure merging is not to be used. The reason is that the percentage of
294 - procedure and function calls is part of the "Dhrystone distribution" of
295 - statements contained in [1]. This restriction does not hold for the string
296 - functions of the C version since ANSI C allows an implementation to use
297 - inline code for these functions.
298 -
299 -o Other optimizations are allowed, but they should be indicated
300 -
301 - It is often hard to draw an exact line between "normal code generation" and
302 - "optimization" in compilers: Some compilers perform operations by default
303 - that are invoked in other compilers only when optimization is explicitly
304 - requested. Also, we cannot avoid that in benchmarking people try to achieve
305 - results that look as good as possible. Therefore, optimizations performed
306 - by compilers - other than those listed above - are not forbidden when
307 - Dhrystone execution times are measured. Dhrystone is not intended to be
308 - non-optimizable but is intended to be similarly optimizable as normal
309 - programs. For example, there are several places in Dhrystone where
310 - performance benefits from optimizations like common subexpression
311 - elimination, value propagation etc., but normal programs usually also
312 - benefit from these optimizations. Therefore, no effort was made to
313 - artificially prevent such optimizations. However, measurement reports
314 - should indicate which compiler optimization levels have been used, and
315 - reporting results with different levels of compiler optimization for the
316 - same hardware is encouraged.
317 -
318 -o Default results are those without "register" declarations (C version)
319 -
320 - When Dhrystone results are quoted without additional qualification, they
321 - should be understood as results obtained without use of the "register"
322 - attribute. Good compilers should be able to make good use of registers even
323 - without explicit register declarations ([3], p. 193).
324 -
325 -Of course, for experimental purposes, post-linkage optimization, procedure
326 -merging and/or compilation in one unit can be done to determine their effects.
327 -However, Dhrystone numbers obtained under these conditions should be
328 -explicitly marked as such; "normal" Dhrystone results should be understood as
329 -results obtained following the ground rules listed above.
330 -
331 -In any case, for serious performance evaluation, users are advised to ask for
332 -code listings and to check them carefully. In this way, when results for
333 -different systems are compared, the reader can get a feeling how much
334 -performance difference is due to compiler optimization and how much is due to
335 -hardware speed.
336 -
337 -
338 -6. Acknowledgements
339 -
340 -The C version 2.1 of Dhrystone has been developed in cooperation with Rick
341 -Richardson (Tinton Falls, NJ), it incorporates many ideas from the "Version
342 -1.1" distributed previously by him over the UNIX network Usenet. Through his
343 -activity with Usenet, Rick Richardson has made a very valuable contribution to
344 -the dissemination of the benchmark. I also thank Chaim Benedelac (National
345 -Semiconductor), David Ditzel (SUN), Earl Killian and John Mashey (MIPS), Alan
346 -Smith and Rafael Saavedra-Barrera (UC at Berkeley) for their help with
347 -comments on earlier versions of the benchmark.
348 -
349 -
350 -7. Bibliography
351 -
352 -[1]
353 - Reinhold P. Weicker: Dhrystone: A Synthetic Systems Programming Benchmark.
354 - Communications of the ACM 27, 10 (Oct. 1984), 1013-1030
355 -
356 -[2]
357 - Rick Richardson: Dhrystone 1.1 Benchmark Summary (and Program Text)
358 - Informal Distribution via "Usenet", Last Version Known to me: Sept. 21,
359 - 1987
360 -
361 -[3]
362 - Brian W. Kernighan and Dennis M. Ritchie: The C Programming Language.
363 - Prentice-Hall, Englewood Cliffs (NJ) 1978
364 -
365 //GO.SYSIN DD RATIONALE
366 echo README_C 1>&2
367 sed >README_C <<'//GO.SYSIN DD README_C' 's/^-//'
368 -This "shar" file contains the documentation for the
369 -electronic mail distribution of the Dhrystone benchmark (C version 2.1);
370 -a companion "shar" file contains the source code.
371 -(Because of mail length restrictions for some mailers, I have
372 -split the distribution in two parts.)
373 -
374 -For versions in other languages, see the other "shar" files.
375 -
376 -Files containing the C version (*.h: Header File, *.c: C Modules)
377 -
378 - dhry.h
379 - dhry_1.c
380 - dhry_2.c
381 -
382 -The file RATIONALE contains the article
383 -
384 - "Dhrystone Benchmark: Rationale for Version 2 and Measurement Rules"
385 -
386 -which has been published, together with the C source code (Version 2.0),
387 -in SIGPLAN Notices vol. 23, no. 8 (Aug. 1988), pp. 49-62.
388 -This article explains all changes that have been made for Version 2,
389 -compared with the version of the original publication
390 -in Communications of the ACM vol. 27, no. 10 (Oct. 1984), pp. 1013-1030.
391 -It also contains "ground rules" for benchmarking with Dhrystone
392 -which should be followed by everyone who uses the program and publishes
393 -Dhrystone results.
394 -
395 -Compared with the Version 2.0 published in SIGPLAN Notices, Version 2.1
396 -contains a few corrections that have been made after Version 2.0 was
397 -distriobuted over the UNIX network Usenet. These small differences between
398 -Version 2.0 and 2.1 should not affect execution time measurements.
399 -For those who want to compare the exact contents of both versions,
400 -the file "dhry_c.dif" contains the differences between the two versions,
401 -as generated by a file comparison of the corresponding files with the
402 -UNIX utility "diff".
403 -
404 -The file VARIATIONS contains the article
405 -
406 - "Understanding Variations in Dhrystone Performance"
407 -
408 -which has been published in Microprocessor Report, May 1989
409 -(Editor: M. Slater), pp. 16-17. It describes the points that users
410 -should know if C Dhrystone results are compared.
411 -
412 -Recipients of this shar file who perform measurements are asked
413 -to send measurement results to the author and/or to Rick Richardson.
414 -Rick Richardson publishes regularly Dhrystone results on the UNIX network
415 -Usenet. For submissions of results to him (preferably by electronic mail,
416 -see address in the program header), he has provided a form which is contained
417 -in the file "submit.frm".
418 -
419 -
420 -The following files are contained in other "shar" files:
421 -
422 -Files containing the Ada version (*.s: Specifications, *.b: Bodies):
423 -
424 - d_global.s
425 - d_main.b
426 - d_pack_1.b
427 - d_pack_1.s
428 - d_pack_2.b
429 - d_pack_2.s
430 -
431 -File containing the Pascal version:
432 -
433 - dhry.p
434 -
435 -
436 -February 22, 1990
437 -
438 - Reinhold P. Weicker
439 - Siemens AG, AUT E 51
440 - Postfach 3220
441 - D-8520 Erlangen
442 - Germany (West)
443 -
444 - Phone: [xxx-49]-9131-7-20330 (8-17 Central European Time)
445 - UUCP: ..!mcsun!unido!estevax!weicker
446 //GO.SYSIN DD README_C
447 echo VARIATIONS 1>&2
448 sed >VARIATIONS <<'//GO.SYSIN DD VARIATIONS' 's/^-//'
449 -
450 - Understanding Variations in Dhrystone Performance
451 -
452 -
453 -
454 - By Reinhold P. Weicker, Siemens AG, AUT E 51, Erlangen
455 -
456 -
457 -
458 - April 1989
459 -
460 -
461 - This article has appeared in:
462 -
463 -
464 - Microprocessor Report, May 1989 (Editor: M. Slater), pp. 16-17
465 -
466 -
467 -
468 -
469 -Microprocessor manufacturers tend to credit all the performance measured by
470 -benchmarks to the speed of their processors, they often don't even mention the
471 -programming language and compiler used. In their detailed documents, usually
472 -called "performance brief" or "performance report," they usually do give more
473 -details. However, these details are often lost in the press releases and other
474 -marketing statements. For serious performance evaluation, it is necessary to
475 -study the code generated by the various compilers.
476 -
477 -Dhrystone was originally published in Ada (Communications of the ACM, Oct.
478 -1984). However, since good Ada compilers were rare at this time and, together
479 -with UNIX, C became more and more popular, the C version of Dhrystone is the
480 -one now mainly used in industry. There are "official" versions 2.1 for Ada,
481 -Pascal, and C, which are as close together as the languages' semantic
482 -differences permit.
483 -
484 -Dhrystone contains two statements where the programming language and its
485 -translation play a major part in the execution time measured by the benchmark:
486 -
487 - o String assignment (in procedure Proc_0 / main)
488 - o String comparison (in function Func_2)
489 -
490 -In Ada and Pascal, strings are arrays of characters where the length of the
491 -string is part of the type information known at compile time. In C, strings
492 -are also arrays of characters, but there are no operators defined in the
493 -language for assignment and comparison of strings. Instead, functions
494 -"strcpy" and "strcmp" are used. These functions are defined for strings of
495 -arbitrary length, and make use of the fact that strings in C have to end with
496 -a terminating null byte. For general-purpose calls to these functions, the
497 -implementor can assume nothing about the length and the alignment of the
498 -strings involved.
499 -
500 -The C version of Dhrystone spends a relatively large amount of time in these
501 -two functions. Some time ago, I made measurements on a VAX 11/785 with the
502 -Berkeley UNIX (4.2) compilers (often-used compilers, but certainly not the
503 -most advanced). In the C version, 23% of the time was spent in the string
504 -functions; in the Pascal version, only 10%. On good RISC machines (where less
505 -time is spent in the procedure calling sequence than on a VAX) and with better
506 -optimizing compilers, the percentage is higher; MIPS has reported 34% for an
507 -R3000. Because of this effect, Pascal and Ada Dhrystone results are usually
508 -better than C results (except when the optimization quality of the C compiler
509 -is considerably better than that of the other compilers).
510 -
511 -Several people have noted that the string operations are over-represented in
512 -Dhrystone, mainly because the strings occurring in Dhrystone are longer than
513 -average strings. I admit that this is true, and have said so in my SIGPLAN
514 -Notices paper (Aug. 1988); however, I didn't want to generate confusion by
515 -changing the string lengths from version 1 to version 2.
516 -
517 -Even if they are somewhat over-represented in Dhrystone, string operations are
518 -frequent enough that it makes sense to implement them in the most efficient
519 -way possible, not only for benchmarking purposes. This means that they can
520 -and should be written in assembly language code. ANSI C also explicitly allows
521 -the strings functions to be implemented as macros, i.e. by inline code.
522 -
523 -There is also a third way to speed up the "strcpy" statement in Dhrystone: For
524 -this particular "strcpy" statement, the source of the assignment is a string
525 -constant. Therefore, in contrast to calls to "strcpy" in the general case, the
526 -compiler knows the length and alignment of the strings involved at compile
527 -time and can generate code in the same efficient way as a Pascal compiler
528 -(word instructions instead of byte instructions).
529 -
530 -This is not allowed in the case of the "strcmp" call: Here, the addresses are
531 -formal procedure parameters, and no assumptions can be made about the length
532 -or alignment of the strings. Any such assumptions would indicate an incorrect
533 -implementation. They might work for Dhrystone, where the strings are in fact
534 -word-aligned with typical compilers, but other programs would deliver
535 -incorrect results.
536 -
537 -So, for an apple-to-apple comparison between processors, and not between
538 -several possible (legal or illegal) degrees of compiler optimization, one
539 -should check that the systems are comparable with respect to the following
540 -three points:
541 -
542 - (1) String functions in assembly language vs. in C
543 -
544 - Frequently used functions such as the string functions can and should be
545 - written in assembly language, and all serious C language systems known
546 - to me do this. (I list this point for completeness only.) Note that
547 - processors with an instruction that checks a word for a null byte (such
548 - as AMD's 29000 and Intel's 80960) have an advantage here. (This
549 - advantage decreases relatively if optimization (3) is applied.) Due to
550 - the length of the strings involved in Dhrystone, this advantage may be
551 - considered too high in perspective, but it is certainly legal to use
552 - such instructions - after all, these situations are what they were
553 - invented for.
554 -
555 - (2) String function code inline vs. as library functions.
556 -
557 - ANSI C has created a new situation, compared with the older
558 - Kernighan/Ritchie C. In the original C, the definition of the string
559 - function was not part of the language. Now it is, and inlining is
560 - explicitly allowed. I probably should have stated more clearly in my
561 - SIGPLAN Notices paper that the rule "No procedure inlining for
562 - Dhrystone" referred to the user level procedures only and not to the
563 - library routines.
564 -
565 - (3) Fixed-length and alignment assumptions for the strings
566 -
567 - Compilers should be allowed to optimize in these cases if (and only if)
568 - it is safe to do so. For Dhrystone, this is the "strcpy" statement, but
569 - not the "strcmp" statement (unless, of course, the "strcmp" code
570 - explicitly checks the alignment at execution time and branches
571 - accordingly). A "Dhrystone switch" for the compiler that causes the
572 - generation of code that may not work under certain circumstances is
573 - certainly inappropriate for comparisons. It has been reported in Usenet
574 - that some C compilers provide such a compiler option; since I don't have
575 - access to all C compilers involved, I cannot verify this.
576 -
577 - If the fixed-length and word-alignment assumption can be used, a wide
578 - bus that permits fast multi-word load instructions certainly does help;
579 - however, this fact by itself should not make a really big difference.
580 -
581 -A check of these points - something that is necessary for a thorough
582 -evaluation and comparison of the Dhrystone performance claims - requires
583 -object code listings as well as listings for the string functions (strcpy,
584 -strcmp) that are possibly called by the program.
585 -
586 -I don't pretend that Dhrystone is a perfect tool to measure the integer
587 -performance of microprocessors. The more it is used and discussed, the more I
588 -myself learn about aspects that I hadn't noticed yet when I wrote the program.
589 -And of course, the very success of a benchmark program is a danger in that
590 -people may tune their compilers and/or hardware to it, and with this action
591 -make it less useful.
592 -
593 -Whetstone and Linpack have their critical points also: The Whetstone rating
594 -depends heavily on the speed of the mathematical functions (sine, sqrt, ...),
595 -and Linpack is sensitive to data alignment for some cache configurations.
596 -
597 -Introduction of a standard set of public domain benchmark software (something
598 -the SPEC effort attempts) is certainly a worthwhile thing. In the meantime,
599 -people will continue to use whatever is available and widely distributed, and
600 -Dhrystone ratings are probably still better than MIPS ratings if these are -
601 -as often in industry - based on no reproducible derivation. However, any
602 -serious performance evaluation requires more than just a comparison of raw
603 -numbers; one has to make sure that the numbers have been obtained in a
604 -comparable way.
605 -
606 //GO.SYSIN DD VARIATIONS
607 echo dhry.h 1>&2
608 sed >dhry.h <<'//GO.SYSIN DD dhry.h' 's/^-//'
609 -/*
610 - ****************************************************************************
611 - *
612 - * "DHRYSTONE" Benchmark Program
613 - * -----------------------------
614 - *
615 - * Version: C, Version 2.1
616 - *
617 - * File: dhry.h (part 1 of 3)
618 - *
619 - * Date: May 25, 1988
620 - *
621 - * Author: Reinhold P. Weicker
622 - * Siemens AG, AUT E 51
623 - * Postfach 3220
624 - * 8520 Erlangen
625 - * Germany (West)
626 - * Phone: [+49]-9131-7-20330
627 - * (8-17 Central European Time)
628 - * Usenet: ..!mcsun!unido!estevax!weicker
629 - *
630 - * Original Version (in Ada) published in
631 - * "Communications of the ACM" vol. 27., no. 10 (Oct. 1984),
632 - * pp. 1013 - 1030, together with the statistics
633 - * on which the distribution of statements etc. is based.
634 - *
635 - * In this C version, the following C library functions are used:
636 - * - strcpy, strcmp (inside the measurement loop)
637 - * - printf, scanf (outside the measurement loop)
638 - * In addition, Berkeley UNIX system calls "times ()" or "time ()"
639 - * are used for execution time measurement. For measurements
640 - * on other systems, these calls have to be changed.
641 - *
642 - * Collection of Results:
643 - * Reinhold Weicker (address see above) and
644 - *
645 - * Rick Richardson
646 - * PC Research. Inc.
647 - * 94 Apple Orchard Drive
648 - * Tinton Falls, NJ 07724
649 - * Phone: (201) 389-8963 (9-17 EST)
650 - * Usenet: ...!uunet!pcrat!rick
651 - *
652 - * Please send results to Rick Richardson and/or Reinhold Weicker.
653 - * Complete information should be given on hardware and software used.
654 - * Hardware information includes: Machine type, CPU, type and size
655 - * of caches; for microprocessors: clock frequency, memory speed
656 - * (number of wait states).
657 - * Software information includes: Compiler (and runtime library)
658 - * manufacturer and version, compilation switches, OS version.
659 - * The Operating System version may give an indication about the
660 - * compiler; Dhrystone itself performs no OS calls in the measurement loop.
661 - *
662 - * The complete output generated by the program should be mailed
663 - * such that at least some checks for correctness can be made.
664 - *
665 - ***************************************************************************
666 - *
667 - * History: This version C/2.1 has been made for two reasons:
668 - *
669 - * 1) There is an obvious need for a common C version of
670 - * Dhrystone, since C is at present the most popular system
671 - * programming language for the class of processors
672 - * (microcomputers, minicomputers) where Dhrystone is used most.
673 - * There should be, as far as possible, only one C version of
674 - * Dhrystone such that results can be compared without
675 - * restrictions. In the past, the C versions distributed
676 - * by Rick Richardson (Version 1.1) and by Reinhold Weicker
677 - * had small (though not significant) differences.
678 - *
679 - * 2) As far as it is possible without changes to the Dhrystone
680 - * statistics, optimizing compilers should be prevented from
681 - * removing significant statements.
682 - *
683 - * This C version has been developed in cooperation with
684 - * Rick Richardson (Tinton Falls, NJ), it incorporates many
685 - * ideas from the "Version 1.1" distributed previously by
686 - * him over the UNIX network Usenet.
687 - * I also thank Chaim Benedelac (National Semiconductor),
688 - * David Ditzel (SUN), Earl Killian and John Mashey (MIPS),
689 - * Alan Smith and Rafael Saavedra-Barrera (UC at Berkeley)
690 - * for their help with comments on earlier versions of the
691 - * benchmark.
692 - *
693 - * Changes: In the initialization part, this version follows mostly
694 - * Rick Richardson's version distributed via Usenet, not the
695 - * version distributed earlier via floppy disk by Reinhold Weicker.
696 - * As a concession to older compilers, names have been made
697 - * unique within the first 8 characters.
698 - * Inside the measurement loop, this version follows the
699 - * version previously distributed by Reinhold Weicker.
700 - *
701 - * At several places in the benchmark, code has been added,
702 - * but within the measurement loop only in branches that
703 - * are not executed. The intention is that optimizing compilers
704 - * should be prevented from moving code out of the measurement
705 - * loop, or from removing code altogether. Since the statements
706 - * that are executed within the measurement loop have NOT been
707 - * changed, the numbers defining the "Dhrystone distribution"
708 - * (distribution of statements, operand types and locality)
709 - * still hold. Except for sophisticated optimizing compilers,
710 - * execution times for this version should be the same as
711 - * for previous versions.
712 - *
713 - * Since it has proven difficult to subtract the time for the
714 - * measurement loop overhead in a correct way, the loop check
715 - * has been made a part of the benchmark. This does have
716 - * an impact - though a very minor one - on the distribution
717 - * statistics which have been updated for this version.
718 - *
719 - * All changes within the measurement loop are described
720 - * and discussed in the companion paper "Rationale for
721 - * Dhrystone version 2".
722 - *
723 - * Because of the self-imposed limitation that the order and
724 - * distribution of the executed statements should not be
725 - * changed, there are still cases where optimizing compilers
726 - * may not generate code for some statements. To a certain
727 - * degree, this is unavoidable for small synthetic benchmarks.
728 - * Users of the benchmark are advised to check code listings
729 - * whether code is generated for all statements of Dhrystone.
730 - *
731 - * Version 2.1 is identical to version 2.0 distributed via
732 - * the UNIX network Usenet in March 1988 except that it corrects
733 - * some minor deficiencies that were found by users of version 2.0.
734 - * The only change within the measurement loop is that a
735 - * non-executed "else" part was added to the "if" statement in
736 - * Func_3, and a non-executed "else" part removed from Proc_3.
737 - *
738 - ***************************************************************************
739 - *
740 - * Defines: The following "Defines" are possible:
741 - * -DREG=register (default: Not defined)
742 - * As an approximation to what an average C programmer
743 - * might do, the "register" storage class is applied
744 - * (if enabled by -DREG=register)
745 - * - for local variables, if they are used (dynamically)
746 - * five or more times
747 - * - for parameters if they are used (dynamically)
748 - * six or more times
749 - * Note that an optimal "register" strategy is
750 - * compiler-dependent, and that "register" declarations
751 - * do not necessarily lead to faster execution.
752 - * -DNOSTRUCTASSIGN (default: Not defined)
753 - * Define if the C compiler does not support
754 - * assignment of structures.
755 - * -DNOENUMS (default: Not defined)
756 - * Define if the C compiler does not support
757 - * enumeration types.
758 - * -DTIMES (default)
759 - * -DTIME
760 - * The "times" function of UNIX (returning process times)
761 - * or the "time" function (returning wallclock time)
762 - * is used for measurement.
763 - * For single user machines, "time ()" is adequate. For
764 - * multi-user machines where you cannot get single-user
765 - * access, use the "times ()" function. If you have
766 - * neither, use a stopwatch in the dead of night.
767 - * "printf"s are provided marking the points "Start Timer"
768 - * and "Stop Timer". DO NOT use the UNIX "time(1)"
769 - * command, as this will measure the total time to
770 - * run this program, which will (erroneously) include
771 - * the time to allocate storage (malloc) and to perform
772 - * the initialization.
773 - * -DHZ=nnn
774 - * In Berkeley UNIX, the function "times" returns process
775 - * time in 1/HZ seconds, with HZ = 60 for most systems.
776 - * CHECK YOUR SYSTEM DESCRIPTION BEFORE YOU JUST APPLY
777 - * A VALUE.
778 - *
779 - ***************************************************************************
780 - *
781 - * Compilation model and measurement (IMPORTANT):
782 - *
783 - * This C version of Dhrystone consists of three files:
784 - * - dhry.h (this file, containing global definitions and comments)
785 - * - dhry_1.c (containing the code corresponding to Ada package Pack_1)
786 - * - dhry_2.c (containing the code corresponding to Ada package Pack_2)
787 - *
788 - * The following "ground rules" apply for measurements:
789 - * - Separate compilation
790 - * - No procedure merging
791 - * - Otherwise, compiler optimizations are allowed but should be indicated
792 - * - Default results are those without register declarations
793 - * See the companion paper "Rationale for Dhrystone Version 2" for a more
794 - * detailed discussion of these ground rules.
795 - *
796 - * For 16-Bit processors (e.g. 80186, 80286), times for all compilation
797 - * models ("small", "medium", "large" etc.) should be given if possible,
798 - * together with a definition of these models for the compiler system used.
799 - *
800 - **************************************************************************
801 - *
802 - * Dhrystone (C version) statistics:
803 - *
804 - * [Comment from the first distribution, updated for version 2.
805 - * Note that because of language differences, the numbers are slightly
806 - * different from the Ada version.]
807 - *
808 - * The following program contains statements of a high level programming
809 - * language (here: C) in a distribution considered representative:
810 - *
811 - * assignments 52 (51.0 %)
812 - * control statements 33 (32.4 %)
813 - * procedure, function calls 17 (16.7 %)
814 - *
815 - * 103 statements are dynamically executed. The program is balanced with
816 - * respect to the three aspects:
817 - *
818 - * - statement type
819 - * - operand type
820 - * - operand locality
821 - * operand global, local, parameter, or constant.
822 - *
823 - * The combination of these three aspects is balanced only approximately.
824 - *
825 - * 1. Statement Type:
826 - * ----------------- number
827 - *
828 - * V1 = V2 9
829 - * (incl. V1 = F(..)
830 - * V = Constant 12
831 - * Assignment, 7
832 - * with array element
833 - * Assignment, 6
834 - * with record component
835 - * --
836 - * 34 34
837 - *
838 - * X = Y +|-|"&&"|"|" Z 5
839 - * X = Y +|-|"==" Constant 6
840 - * X = X +|- 1 3
841 - * X = Y *|/ Z 2
842 - * X = Expression, 1
843 - * two operators
844 - * X = Expression, 1
845 - * three operators
846 - * --
847 - * 18 18
848 - *
849 - * if .... 14
850 - * with "else" 7
851 - * without "else" 7
852 - * executed 3
853 - * not executed 4
854 - * for ... 7 | counted every time
855 - * while ... 4 | the loop condition
856 - * do ... while 1 | is evaluated
857 - * switch ... 1
858 - * break 1
859 - * declaration with 1
860 - * initialization
861 - * --
862 - * 34 34
863 - *
864 - * P (...) procedure call 11
865 - * user procedure 10
866 - * library procedure 1
867 - * X = F (...)
868 - * function call 6
869 - * user function 5
870 - * library function 1
871 - * --
872 - * 17 17
873 - * ---
874 - * 103
875 - *
876 - * The average number of parameters in procedure or function calls
877 - * is 1.82 (not counting the function values as implicit parameters).
878 - *
879 - *
880 - * 2. Operators
881 - * ------------
882 - * number approximate
883 - * percentage
884 - *
885 - * Arithmetic 32 50.8
886 - *
887 - * + 21 33.3
888 - * - 7 11.1
889 - * * 3 4.8
890 - * / (int div) 1 1.6
891 - *
892 - * Comparison 27 42.8
893 - *
894 - * == 9 14.3
895 - * /= 4 6.3
896 - * > 1 1.6
897 - * < 3 4.8
898 - * >= 1 1.6
899 - * <= 9 14.3
900 - *
901 - * Logic 4 6.3
902 - *
903 - * && (AND-THEN) 1 1.6
904 - * | (OR) 1 1.6
905 - * ! (NOT) 2 3.2
906 - *
907 - * -- -----
908 - * 63 100.1
909 - *
910 - *
911 - * 3. Operand Type (counted once per operand reference):
912 - * ---------------
913 - * number approximate
914 - * percentage
915 - *
916 - * Integer 175 72.3 %
917 - * Character 45 18.6 %
918 - * Pointer 12 5.0 %
919 - * String30 6 2.5 %
920 - * Array 2 0.8 %
921 - * Record 2 0.8 %
922 - * --- -------
923 - * 242 100.0 %
924 - *
925 - * When there is an access path leading to the final operand (e.g. a record
926 - * component), only the final data type on the access path is counted.
927 - *
928 - *
929 - * 4. Operand Locality:
930 - * -------------------
931 - * number approximate
932 - * percentage
933 - *
934 - * local variable 114 47.1 %
935 - * global variable 22 9.1 %
936 - * parameter 45 18.6 %
937 - * value 23 9.5 %
938 - * reference 22 9.1 %
939 - * function result 6 2.5 %
940 - * constant 55 22.7 %
941 - * --- -------
942 - * 242 100.0 %
943 - *
944 - *
945 - * The program does not compute anything meaningful, but it is syntactically
946 - * and semantically correct. All variables have a value assigned to them
947 - * before they are used as a source operand.
948 - *
949 - * There has been no explicit effort to account for the effects of a
950 - * cache, or to balance the use of long or short displacements for code or
951 - * data.
952 - *
953 - ***************************************************************************
954 - */
955 -
956 -/* Compiler and system dependent definitions: */
957 -
958 -#ifndef TIME
959 -#define TIMES
960 -#endif
961 - /* Use times(2) time function unless */
962 - /* explicitly defined otherwise */
963 -
964 -#ifdef TIMES
965 -#include <sys/types.h>
966 -#include <sys/times.h>
967 - /* for "times" */
968 -#endif
969 -
970 -#define Mic_secs_Per_Second 1000000.0
971 - /* Berkeley UNIX C returns process times in seconds/HZ */
972 -
973 -#ifdef NOSTRUCTASSIGN
974 -#define structassign(d, s) memcpy(&(d), &(s), sizeof(d))
975 -#else
976 -#define structassign(d, s) d = s
977 -#endif
978 -
979 -#ifdef NOENUM
980 -#define Ident_1 0
981 -#define Ident_2 1
982 -#define Ident_3 2
983 -#define Ident_4 3
984 -#define Ident_5 4
985 - typedef int Enumeration;
986 -#else
987 - typedef enum {Ident_1, Ident_2, Ident_3, Ident_4, Ident_5}
988 - Enumeration;
989 -#endif
990 - /* for boolean and enumeration types in Ada, Pascal */
991 -
992 -/* General definitions: */
993 -
994 -#include <stdio.h>
995 - /* for strcpy, strcmp */
996 -
997 -#define Null 0
998 - /* Value of a Null pointer */
999 -#define true 1
1000 -#define false 0
1001 -
1002 -typedef int One_Thirty;
1003 -typedef int One_Fifty;
1004 -typedef char Capital_Letter;
1005 -typedef int Boolean;
1006 -typedef char Str_30 [31];
1007 -typedef int Arr_1_Dim [50];
1008 -typedef int Arr_2_Dim [50] [50];
1009 -
1010 -typedef struct record
1011 - {
1012 - struct record *Ptr_Comp;
1013 - Enumeration Discr;
1014 - union {
1015 - struct {
1016 - Enumeration Enum_Comp;
1017 - int Int_Comp;
1018 - char Str_Comp [31];
1019 - } var_1;
1020 - struct {
1021 - Enumeration E_Comp_2;
1022 - char Str_2_Comp [31];
1023 - } var_2;
1024 - struct {
1025 - char Ch_1_Comp;
1026 - char Ch_2_Comp;
1027 - } var_3;
1028 - } variant;
1029 - } Rec_Type, *Rec_Pointer;
1030 -
1031 -
1032 //GO.SYSIN DD dhry.h
1033 echo dhry_1.c 1>&2
1034 sed >dhry_1.c <<'//GO.SYSIN DD dhry_1.c' 's/^-//'
1035 -/*
1036 - ****************************************************************************
1037 - *
1038 - * "DHRYSTONE" Benchmark Program
1039 - * -----------------------------
1040 - *
1041 - * Version: C, Version 2.1
1042 - *
1043 - * File: dhry_1.c (part 2 of 3)
1044 - *
1045 - * Date: May 25, 1988
1046 - *
1047 - * Author: Reinhold P. Weicker
1048 - *
1049 - ****************************************************************************
1050 - */
1051 -
1052 -#include "dhry.h"
1053 -
1054 -/* Global Variables: */
1055 -
1056 -Rec_Pointer Ptr_Glob,
1057 - Next_Ptr_Glob;
1058 -int Int_Glob;
1059 -Boolean Bool_Glob;
1060 -char Ch_1_Glob,
1061 - Ch_2_Glob;
1062 -int Arr_1_Glob [50];
1063 -int Arr_2_Glob [50] [50];
1064 -
1065 -extern char *malloc ();
1066 -Enumeration Func_1 ();
1067 - /* forward declaration necessary since Enumeration may not simply be int */
1068 -
1069 -#ifndef REG
1070 - Boolean Reg = false;
1071 -#define REG
1072 - /* REG becomes defined as empty */
1073 - /* i.e. no register variables */
1074 -#else
1075 - Boolean Reg = true;
1076 -#endif
1077 -
1078 -/* variables for time measurement: */
1079 -
1080 -#ifdef TIMES
1081 -struct tms time_info;
1082 -extern int times ();
1083 - /* see library function "times" */
1084 -#define Too_Small_Time 120
1085 - /* Measurements should last at least about 2 seconds */
1086 -#endif
1087 -#ifdef TIME
1088 -extern long time();
1089 - /* see library function "time" */
1090 -#define Too_Small_Time 2
1091 - /* Measurements should last at least 2 seconds */
1092 -#endif
1093 -
1094 -long Begin_Time,
1095 - End_Time,
1096 - User_Time;
1097 -float Microseconds,
1098 - Dhrystones_Per_Second;
1099 -
1100 -/* end of variables for time measurement */
1101 -
1102 -
1103 -main ()
1104 -/*****/
1105 -
1106 - /* main program, corresponds to procedures */
1107 - /* Main and Proc_0 in the Ada version */
1108 -{
1109 - One_Fifty Int_1_Loc;
1110 - REG One_Fifty Int_2_Loc;
1111 - One_Fifty Int_3_Loc;
1112 - REG char Ch_Index;
1113 - Enumeration Enum_Loc;
1114 - Str_30 Str_1_Loc;
1115 - Str_30 Str_2_Loc;
1116 - REG int Run_Index;
1117 - REG int Number_Of_Runs;
1118 -
1119 - /* Initializations */
1120 -
1121 - Next_Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type));
1122 - Ptr_Glob = (Rec_Pointer) malloc (sizeof (Rec_Type));
1123 -
1124 - Ptr_Glob->Ptr_Comp = Next_Ptr_Glob;
1125 - Ptr_Glob->Discr = Ident_1;
1126 - Ptr_Glob->variant.var_1.Enum_Comp = Ident_3;
1127 - Ptr_Glob->variant.var_1.Int_Comp = 40;
1128 - strcpy (Ptr_Glob->variant.var_1.Str_Comp,
1129 - "DHRYSTONE PROGRAM, SOME STRING");
1130 - strcpy (Str_1_Loc, "DHRYSTONE PROGRAM, 1'ST STRING");
1131 -
1132 - Arr_2_Glob [8][7] = 10;
1133 - /* Was missing in published program. Without this statement, */
1134 - /* Arr_2_Glob [8][7] would have an undefined value. */
1135 - /* Warning: With 16-Bit processors and Number_Of_Runs > 32000, */
1136 - /* overflow may occur for this array element. */
1137 -
1138 - printf ("\n");
1139 - printf ("Dhrystone Benchmark, Version 2.1 (Language: C)\n");
1140 - printf ("\n");
1141 - if (Reg)
1142 - {
1143 - printf ("Program compiled with 'register' attribute\n");
1144 - printf ("\n");
1145 - }
1146 - else
1147 - {
1148 - printf ("Program compiled without 'register' attribute\n");
1149 - printf ("\n");
1150 - }
1151 - printf ("Please give the number of runs through the benchmark: ");
1152 - {
1153 - int n;
1154 - scanf ("%d", &n);
1155 - Number_Of_Runs = n;
1156 - }
1157 - printf ("\n");
1158 -
1159 - printf ("Execution starts, %d runs through Dhrystone\n", Number_Of_Runs);
1160 -
1161 - /***************/
1162 - /* Start timer */
1163 - /***************/
1164 -
1165 -#ifdef TIMES
1166 - times (&time_info);
1167 - Begin_Time = (long) time_info.tms_utime;
1168 -#endif
1169 -#ifdef TIME
1170 - Begin_Time = time ( (long *) 0);
1171 -#endif
1172 -
1173 - for (Run_Index = 1; Run_Index <= Number_Of_Runs; ++Run_Index)
1174 - {
1175 -
1176 - Proc_5();
1177 - Proc_4();
1178 - /* Ch_1_Glob == 'A', Ch_2_Glob == 'B', Bool_Glob == true */
1179 - Int_1_Loc = 2;
1180 - Int_2_Loc = 3;
1181 - strcpy (Str_2_Loc, "DHRYSTONE PROGRAM, 2'ND STRING");
1182 - Enum_Loc = Ident_2;
1183 - Bool_Glob = ! Func_2 (Str_1_Loc, Str_2_Loc);
1184 - /* Bool_Glob == 1 */
1185 - while (Int_1_Loc < Int_2_Loc) /* loop body executed once */
1186 - {
1187 - Int_3_Loc = 5 * Int_1_Loc - Int_2_Loc;
1188 - /* Int_3_Loc == 7 */
1189 - Proc_7 (Int_1_Loc, Int_2_Loc, &Int_3_Loc);
1190 - /* Int_3_Loc == 7 */
1191 - Int_1_Loc += 1;
1192 - } /* while */
1193 - /* Int_1_Loc == 3, Int_2_Loc == 3, Int_3_Loc == 7 */
1194 - Proc_8 (Arr_1_Glob, Arr_2_Glob, Int_1_Loc, Int_3_Loc);
1195 - /* Int_Glob == 5 */
1196 - Proc_1 (Ptr_Glob);
1197 - for (Ch_Index = 'A'; Ch_Index <= Ch_2_Glob; ++Ch_Index)
1198 - /* loop body executed twice */
1199 - {
1200 - if (Enum_Loc == Func_1 (Ch_Index, 'C'))
1201 - /* then, not executed */
1202 - {
1203 - Proc_6 (Ident_1, &Enum_Loc);
1204 - strcpy (Str_2_Loc, "DHRYSTONE PROGRAM, 3'RD STRING");
1205 - Int_2_Loc = Run_Index;
1206 - Int_Glob = Run_Index;
1207 - }
1208 - }
1209 - /* Int_1_Loc == 3, Int_2_Loc == 3, Int_3_Loc == 7 */
1210 - Int_2_Loc = Int_2_Loc * Int_1_Loc;
1211 - Int_1_Loc = Int_2_Loc / Int_3_Loc;
1212 - Int_2_Loc = 7 * (Int_2_Loc - Int_3_Loc) - Int_1_Loc;
1213 - /* Int_1_Loc == 1, Int_2_Loc == 13, Int_3_Loc == 7 */
1214 - Proc_2 (&Int_1_Loc);
1215 - /* Int_1_Loc == 5 */
1216 -
1217 - } /* loop "for Run_Index" */
1218 -
1219 - /**************/
1220 - /* Stop timer */
1221 - /**************/
1222 -
1223 -#ifdef TIMES
1224 - times (&time_info);
1225 - End_Time = (long) time_info.tms_utime;
1226 -#endif
1227 -#ifdef TIME
1228 - End_Time = time ( (long *) 0);
1229 -#endif
1230 -
1231 - printf ("Execution ends\n");
1232 - printf ("\n");
1233 - printf ("Final values of the variables used in the benchmark:\n");
1234 - printf ("\n");
1235 - printf ("Int_Glob: %d\n", Int_Glob);
1236 - printf (" should be: %d\n", 5);
1237 - printf ("Bool_Glob: %d\n", Bool_Glob);
1238 - printf (" should be: %d\n", 1);
1239 - printf ("Ch_1_Glob: %c\n", Ch_1_Glob);
1240 - printf (" should be: %c\n", 'A');
1241 - printf ("Ch_2_Glob: %c\n", Ch_2_Glob);
1242 - printf (" should be: %c\n", 'B');
1243 - printf ("Arr_1_Glob[8]: %d\n", Arr_1_Glob[8]);
1244 - printf (" should be: %d\n", 7);
1245 - printf ("Arr_2_Glob[8][7]: %d\n", Arr_2_Glob[8][7]);
1246 - printf (" should be: Number_Of_Runs + 10\n");
1247 - printf ("Ptr_Glob->\n");
1248 - printf (" Ptr_Comp: %d\n", (int) Ptr_Glob->Ptr_Comp);
1249 - printf (" should be: (implementation-dependent)\n");
1250 - printf (" Discr: %d\n", Ptr_Glob->Discr);
1251 - printf (" should be: %d\n", 0);
1252 - printf (" Enum_Comp: %d\n", Ptr_Glob->variant.var_1.Enum_Comp);
1253 - printf (" should be: %d\n", 2);
1254 - printf (" Int_Comp: %d\n", Ptr_Glob->variant.var_1.Int_Comp);
1255 - printf (" should be: %d\n", 17);
1256 - printf (" Str_Comp: %s\n", Ptr_Glob->variant.var_1.Str_Comp);
1257 - printf (" should be: DHRYSTONE PROGRAM, SOME STRING\n");
1258 - printf ("Next_Ptr_Glob->\n");
1259 - printf (" Ptr_Comp: %d\n", (int) Next_Ptr_Glob->Ptr_Comp);
1260 - printf (" should be: (implementation-dependent), same as above\n");
1261 - printf (" Discr: %d\n", Next_Ptr_Glob->Discr);
1262 - printf (" should be: %d\n", 0);
1263 - printf (" Enum_Comp: %d\n", Next_Ptr_Glob->variant.var_1.Enum_Comp);
1264 - printf (" should be: %d\n", 1);
1265 - printf (" Int_Comp: %d\n", Next_Ptr_Glob->variant.var_1.Int_Comp);
1266 - printf (" should be: %d\n", 18);
1267 - printf (" Str_Comp: %s\n",
1268 - Next_Ptr_Glob->variant.var_1.Str_Comp);
1269 - printf (" should be: DHRYSTONE PROGRAM, SOME STRING\n");
1270 - printf ("Int_1_Loc: %d\n", Int_1_Loc);
1271 - printf (" should be: %d\n", 5);
1272 - printf ("Int_2_Loc: %d\n", Int_2_Loc);
1273 - printf (" should be: %d\n", 13);
1274 - printf ("Int_3_Loc: %d\n", Int_3_Loc);
1275 - printf (" should be: %d\n", 7);
1276 - printf ("Enum_Loc: %d\n", Enum_Loc);
1277 - printf (" should be: %d\n", 1);
1278 - printf ("Str_1_Loc: %s\n", Str_1_Loc);
1279 - printf (" should be: DHRYSTONE PROGRAM, 1'ST STRING\n");
1280 - printf ("Str_2_Loc: %s\n", Str_2_Loc);
1281 - printf (" should be: DHRYSTONE PROGRAM, 2'ND STRING\n");
1282 - printf ("\n");
1283 -
1284 - User_Time = End_Time - Begin_Time;
1285 -
1286 - if (User_Time < Too_Small_Time)
1287 - {
1288 - printf ("Measured time too small to obtain meaningful results\n");
1289 - printf ("Please increase number of runs\n");
1290 - printf ("\n");
1291 - }
1292 - else
1293 - {
1294 -#ifdef TIME
1295 - Microseconds = (float) User_Time * Mic_secs_Per_Second
1296 - / (float) Number_Of_Runs;
1297 - Dhrystones_Per_Second = (float) Number_Of_Runs / (float) User_Time;
1298 -#else
1299 - Microseconds = (float) User_Time * Mic_secs_Per_Second
1300 - / ((float) HZ * ((float) Number_Of_Runs));
1301 - Dhrystones_Per_Second = ((float) HZ * (float) Number_Of_Runs)
1302 - / (float) User_Time;
1303 -#endif
1304 - printf ("Microseconds for one run through Dhrystone: ");
1305 - printf ("%6.1f \n", Microseconds);
1306 - printf ("Dhrystones per Second: ");
1307 - printf ("%6.1f \n", Dhrystones_Per_Second);
1308 - printf ("\n");
1309 - }
1310 -
1311 -}
1312 -
1313 -
1314 -Proc_1 (Ptr_Val_Par)
1315 -/******************/
1316 -
1317 -REG Rec_Pointer Ptr_Val_Par;
1318 - /* executed once */
1319 -{
1320 - REG Rec_Pointer Next_Record = Ptr_Val_Par->Ptr_Comp;
1321 - /* == Ptr_Glob_Next */
1322 - /* Local variable, initialized with Ptr_Val_Par->Ptr_Comp, */
1323 - /* corresponds to "rename" in Ada, "with" in Pascal */
1324 -
1325 - structassign (*Ptr_Val_Par->Ptr_Comp, *Ptr_Glob);
1326 - Ptr_Val_Par->variant.var_1.Int_Comp = 5;
1327 - Next_Record->variant.var_1.Int_Comp
1328 - = Ptr_Val_Par->variant.var_1.Int_Comp;
1329 - Next_Record->Ptr_Comp = Ptr_Val_Par->Ptr_Comp;
1330 - Proc_3 (&Next_Record->Ptr_Comp);
1331 - /* Ptr_Val_Par->Ptr_Comp->Ptr_Comp
1332 - == Ptr_Glob->Ptr_Comp */
1333 - if (Next_Record->Discr == Ident_1)
1334 - /* then, executed */
1335 - {
1336 - Next_Record->variant.var_1.Int_Comp = 6;
1337 - Proc_6 (Ptr_Val_Par->variant.var_1.Enum_Comp,
1338 - &Next_Record->variant.var_1.Enum_Comp);
1339 - Next_Record->Ptr_Comp = Ptr_Glob->Ptr_Comp;
1340 - Proc_7 (Next_Record->variant.var_1.Int_Comp, 10,
1341 - &Next_Record->variant.var_1.Int_Comp);
1342 - }
1343 - else /* not executed */
1344 - structassign (*Ptr_Val_Par, *Ptr_Val_Par->Ptr_Comp);
1345 -} /* Proc_1 */
1346 -
1347 -
1348 -Proc_2 (Int_Par_Ref)
1349 -/******************/
1350 - /* executed once */
1351 - /* *Int_Par_Ref == 1, becomes 4 */
1352 -
1353 -One_Fifty *Int_Par_Ref;
1354 -{
1355 - One_Fifty Int_Loc;
1356 - Enumeration Enum_Loc;
1357 -
1358 - Int_Loc = *Int_Par_Ref + 10;
1359 - do /* executed once */
1360 - if (Ch_1_Glob == 'A')
1361 - /* then, executed */
1362 - {
1363 - Int_Loc -= 1;
1364 - *Int_Par_Ref = Int_Loc - Int_Glob;
1365 - Enum_Loc = Ident_1;
1366 - } /* if */
1367 - while (Enum_Loc != Ident_1); /* true */
1368 -} /* Proc_2 */
1369 -
1370 -
1371 -Proc_3 (Ptr_Ref_Par)
1372 -/******************/
1373 - /* executed once */
1374 - /* Ptr_Ref_Par becomes Ptr_Glob */
1375 -
1376 -Rec_Pointer *Ptr_Ref_Par;
1377 -
1378 -{
1379 - if (Ptr_Glob != Null)
1380 - /* then, executed */
1381 - *Ptr_Ref_Par = Ptr_Glob->Ptr_Comp;
1382 - Proc_7 (10, Int_Glob, &Ptr_Glob->variant.var_1.Int_Comp);
1383 -} /* Proc_3 */
1384 -
1385 -
1386 -Proc_4 () /* without parameters */
1387 -/*******/
1388 - /* executed once */
1389 -{
1390 - Boolean Bool_Loc;
1391 -
1392 - Bool_Loc = Ch_1_Glob == 'A';
1393 - Bool_Glob = Bool_Loc | Bool_Glob;
1394 - Ch_2_Glob = 'B';
1395 -} /* Proc_4 */
1396 -
1397 -
1398 -Proc_5 () /* without parameters */
1399 -/*******/
1400 - /* executed once */
1401 -{
1402 - Ch_1_Glob = 'A';
1403 - Bool_Glob = false;
1404 -} /* Proc_5 */
1405 -
1406 -
1407 - /* Procedure for the assignment of structures, */
1408 - /* if the C compiler doesn't support this feature */
1409 -#ifdef NOSTRUCTASSIGN
1410 -memcpy (d, s, l)
1411 -register char *d;
1412 -register char *s;
1413 -register int l;
1414 -{
1415 - while (l--) *d++ = *s++;
1416 -}
1417 -#endif
1418 -
1419 -
1420 //GO.SYSIN DD dhry_1.c
1421 echo dhry_2.c 1>&2
1422 sed >dhry_2.c <<'//GO.SYSIN DD dhry_2.c' 's/^-//'
1423 -/*
1424 - ****************************************************************************
1425 - *
1426 - * "DHRYSTONE" Benchmark Program
1427 - * -----------------------------
1428 - *
1429 - * Version: C, Version 2.1
1430 - *
1431 - * File: dhry_2.c (part 3 of 3)
1432 - *
1433 - * Date: May 25, 1988
1434 - *
1435 - * Author: Reinhold P. Weicker
1436 - *
1437 - ****************************************************************************
1438 - */
1439 -
1440 -#include "dhry.h"
1441 -
1442 -#ifndef REG
1443 -#define REG
1444 - /* REG becomes defined as empty */
1445 - /* i.e. no register variables */
1446 -#endif
1447 -
1448 -extern int Int_Glob;
1449 -extern char Ch_1_Glob;
1450 -
1451 -
1452 -Proc_6 (Enum_Val_Par, Enum_Ref_Par)
1453 -/*********************************/
1454 - /* executed once */
1455 - /* Enum_Val_Par == Ident_3, Enum_Ref_Par becomes Ident_2 */
1456 -
1457 -Enumeration Enum_Val_Par;
1458 -Enumeration *Enum_Ref_Par;
1459 -{
1460 - *Enum_Ref_Par = Enum_Val_Par;
1461 - if (! Func_3 (Enum_Val_Par))
1462 - /* then, not executed */
1463 - *Enum_Ref_Par = Ident_4;
1464 - switch (Enum_Val_Par)
1465 - {
1466 - case Ident_1:
1467 - *Enum_Ref_Par = Ident_1;
1468 - break;
1469 - case Ident_2:
1470 - if (Int_Glob > 100)
1471 - /* then */
1472 - *Enum_Ref_Par = Ident_1;
1473 - else *Enum_Ref_Par = Ident_4;
1474 - break;
1475 - case Ident_3: /* executed */
1476 - *Enum_Ref_Par = Ident_2;
1477 - break;
1478 - case Ident_4: break;
1479 - case Ident_5:
1480 - *Enum_Ref_Par = Ident_3;
1481 - break;
1482 - } /* switch */
1483 -} /* Proc_6 */
1484 -
1485 -
1486 -Proc_7 (Int_1_Par_Val, Int_2_Par_Val, Int_Par_Ref)
1487 -/**********************************************/
1488 - /* executed three times */
1489 - /* first call: Int_1_Par_Val == 2, Int_2_Par_Val == 3, */
1490 - /* Int_Par_Ref becomes 7 */
1491 - /* second call: Int_1_Par_Val == 10, Int_2_Par_Val == 5, */
1492 - /* Int_Par_Ref becomes 17 */
1493 - /* third call: Int_1_Par_Val == 6, Int_2_Par_Val == 10, */
1494 - /* Int_Par_Ref becomes 18 */
1495 -One_Fifty Int_1_Par_Val;
1496 -One_Fifty Int_2_Par_Val;
1497 -One_Fifty *Int_Par_Ref;
1498 -{
1499 - One_Fifty Int_Loc;
1500 -
1501 - Int_Loc = Int_1_Par_Val + 2;
1502 - *Int_Par_Ref = Int_2_Par_Val + Int_Loc;
1503 -} /* Proc_7 */
1504 -
1505 -
1506 -Proc_8 (Arr_1_Par_Ref, Arr_2_Par_Ref, Int_1_Par_Val, Int_2_Par_Val)
1507 -/*********************************************************************/
1508 - /* executed once */
1509 - /* Int_Par_Val_1 == 3 */
1510 - /* Int_Par_Val_2 == 7 */
1511 -Arr_1_Dim Arr_1_Par_Ref;
1512 -Arr_2_Dim Arr_2_Par_Ref;
1513 -int Int_1_Par_Val;
1514 -int Int_2_Par_Val;
1515 -{
1516 - REG One_Fifty Int_Index;
1517 - REG One_Fifty Int_Loc;
1518 -
1519 - Int_Loc = Int_1_Par_Val + 5;
1520 - Arr_1_Par_Ref [Int_Loc] = Int_2_Par_Val;
1521 - Arr_1_Par_Ref [Int_Loc+1] = Arr_1_Par_Ref [Int_Loc];
1522 - Arr_1_Par_Ref [Int_Loc+30] = Int_Loc;
1523 - for (Int_Index = Int_Loc; Int_Index <= Int_Loc+1; ++Int_Index)
1524 - Arr_2_Par_Ref [Int_Loc] [Int_Index] = Int_Loc;
1525 - Arr_2_Par_Ref [Int_Loc] [Int_Loc-1] += 1;
1526 - Arr_2_Par_Ref [Int_Loc+20] [Int_Loc] = Arr_1_Par_Ref [Int_Loc];
1527 - Int_Glob = 5;
1528 -} /* Proc_8 */
1529 -
1530 -
1531 -Enumeration Func_1 (Ch_1_Par_Val, Ch_2_Par_Val)
1532 -/*************************************************/
1533 - /* executed three times */
1534 - /* first call: Ch_1_Par_Val == 'H', Ch_2_Par_Val == 'R' */
1535 - /* second call: Ch_1_Par_Val == 'A', Ch_2_Par_Val == 'C' */
1536 - /* third call: Ch_1_Par_Val == 'B', Ch_2_Par_Val == 'C' */
1537 -
1538 -Capital_Letter Ch_1_Par_Val;
1539 -Capital_Letter Ch_2_Par_Val;
1540 -{
1541 - Capital_Letter Ch_1_Loc;
1542 - Capital_Letter Ch_2_Loc;
1543 -
1544 - Ch_1_Loc = Ch_1_Par_Val;
1545 - Ch_2_Loc = Ch_1_Loc;
1546 - if (Ch_2_Loc != Ch_2_Par_Val)
1547 - /* then, executed */
1548 - return (Ident_1);
1549 - else /* not executed */
1550 - {
1551 - Ch_1_Glob = Ch_1_Loc;
1552 - return (Ident_2);
1553 - }
1554 -} /* Func_1 */
1555 -
1556 -
1557 -Boolean Func_2 (Str_1_Par_Ref, Str_2_Par_Ref)
1558 -/*************************************************/
1559 - /* executed once */
1560 - /* Str_1_Par_Ref == "DHRYSTONE PROGRAM, 1'ST STRING" */
1561 - /* Str_2_Par_Ref == "DHRYSTONE PROGRAM, 2'ND STRING" */
1562 -
1563 -Str_30 Str_1_Par_Ref;
1564 -Str_30 Str_2_Par_Ref;
1565 -{
1566 - REG One_Thirty Int_Loc;
1567 - Capital_Letter Ch_Loc;
1568 -
1569 - Int_Loc = 2;
1570 - while (Int_Loc <= 2) /* loop body executed once */
1571 - if (Func_1 (Str_1_Par_Ref[Int_Loc],
1572 - Str_2_Par_Ref[Int_Loc+1]) == Ident_1)
1573 - /* then, executed */
1574 - {
1575 - Ch_Loc = 'A';
1576 - Int_Loc += 1;
1577 - } /* if, while */
1578 - if (Ch_Loc >= 'W' && Ch_Loc < 'Z')
1579 - /* then, not executed */
1580 - Int_Loc = 7;
1581 - if (Ch_Loc == 'R')
1582 - /* then, not executed */
1583 - return (true);
1584 - else /* executed */
1585 - {
1586 - if (strcmp (Str_1_Par_Ref, Str_2_Par_Ref) > 0)
1587 - /* then, not executed */
1588 - {
1589 - Int_Loc += 7;
1590 - Int_Glob = Int_Loc;
1591 - return (true);
1592 - }
1593 - else /* executed */
1594 - return (false);
1595 - } /* if Ch_Loc */
1596 -} /* Func_2 */
1597 -
1598 -
1599 -Boolean Func_3 (Enum_Par_Val)
1600 -/***************************/
1601 - /* executed once */
1602 - /* Enum_Par_Val == Ident_3 */
1603 -Enumeration Enum_Par_Val;
1604 -{
1605 - Enumeration Enum_Loc;
1606 -
1607 - Enum_Loc = Enum_Par_Val;
1608 - if (Enum_Loc == Ident_3)
1609 - /* then, executed */
1610 - return (true);
1611 - else /* not executed */
1612 - return (false);
1613 -} /* Func_3 */
1614 -
1615 //GO.SYSIN DD dhry_2.c
1616 echo dhry_c.dif 1>&2
1617 sed >dhry_c.dif <<'//GO.SYSIN DD dhry_c.dif' 's/^-//'
1618 -7c7
1619 -< * Version: C, Version 2.1
1620 ----
1621 -> * Version: C, Version 2.0
1622 -9c9
1623 -< * File: dhry.h (part 1 of 3)
1624 ----
1625 -> * File: dhry_global.h (part 1 of 3)
1626 -11c11
1627 -< * Date: May 25, 1988
1628 ----
1629 -> * Date: March 3, 1988
1630 -30c30
1631 -< * In addition, Berkeley UNIX system calls "times ()" or "time ()"
1632 ----
1633 -> * In addition, UNIX system calls "times ()" or "time ()"
1634 -44c44
1635 -< * Please send results to Rick Richardson and/or Reinhold Weicker.
1636 ----
1637 -> * Please send results to Reinhold Weicker and/or Rick Richardson.
1638 -59c59
1639 -< * History: This version C/2.1 has been made for two reasons:
1640 ----
1641 -> * History: This version C/2.0 has been made for two reasons:
1642 -123,129d122
1643 -< * Version 2.1 is identical to version 2.0 distributed via
1644 -< * the UNIX network Usenet in March 1988 except that it corrects
1645 -< * some minor deficiencies that were found by users of version 2.0.
1646 -< * The only change within the measurement loop is that a
1647 -< * non-executed "else" part was added to the "if" statement in
1648 -< * Func_3, and a non-executed "else" part removed from Proc_3.
1649 -< *
1650 -165,167c158,160
1651 -< * -DHZ=nnn
1652 -< * In Berkeley UNIX, the function "times" returns process
1653 -< * time in 1/HZ seconds, with HZ = 60 for most systems.
1654 ----
1655 -> * -DHZ=nnn (default: 60)
1656 -> * The function "times" returns process times in
1657 -> * 1/HZ seconds, with HZ = 60 for most systems.
1658 -169c162
1659 -< * A VALUE.
1660 ----
1661 -> * THE DEFAULT VALUE.
1662 -176,178c169,171
1663 -< * - dhry.h (this file, containing global definitions and comments)
1664 -< * - dhry_1.c (containing the code corresponding to Ada package Pack_1)
1665 -< * - dhry_2.c (containing the code corresponding to Ada package Pack_2)
1666 ----
1667 -> * - dhry_global.h (this file, containing global definitions and comments)
1668 -> * - dhry_pack_1.c (containing the code corresponding to Ada package Pack_1)
1669 -> * - dhry_pack_2.c (containing the code corresponding to Ada package Pack_2)
1670 -350a344
1671 -> #ifndef TIMES
1672 -353,354c347,354
1673 -< /* Use times(2) time function unless */
1674 -< /* explicitly defined otherwise */
1675 ----
1676 -> #endif
1677 -> /* Use "times" function for measurement */
1678 -> /* unless explicitly defined otherwise */
1679 -> #ifndef HZ
1680 -> #define HZ 60
1681 -> #endif
1682 -> /* Use HZ = 60 for "times" function */
1683 -> /* unless explicitly defined otherwise */
1684 -363c363
1685 -< /* Berkeley UNIX C returns process times in seconds/HZ */
1686 ----
1687 -> /* UNIX C returns process times in seconds/HZ */
1688 -7c7
1689 -< * Version: C, Version 2.1
1690 ----
1691 -> * Version: C, Version 2.0
1692 -9c9
1693 -< * File: dhry_1.c (part 2 of 3)
1694 ----
1695 -> * File: dhry_pack_1.c (part 2 of 3)
1696 -11c11
1697 -< * Date: May 25, 1988
1698 ----
1699 -> * Date: March 3, 1988
1700 -18c18
1701 -< #include "dhry.h"
1702 ----
1703 -> #include "dhry_global.h"
1704 -50,51d49
1705 -< #define Too_Small_Time 120
1706 -< /* Measurements should last at least about 2 seconds */
1707 -55a54,55
1708 -> #endif
1709 ->
1710 -58d57
1711 -< #endif
1712 -73a73
1713 ->
1714 -84a85
1715 ->
1716 -99,100c100,102
1717 -< /* Was missing in published program. Without this statement, */
1718 -< /* Arr_2_Glob [8][7] would have an undefined value. */
1719 ----
1720 -> /* Was missing in published program. Without this */
1721 -> /* initialization, Arr_2_Glob [8][7] would have an */
1722 -> /* undefined value. */
1723 -105c107
1724 -< printf ("Dhrystone Benchmark, Version 2.1 (Language: C)\n");
1725 ----
1726 -> printf ("Dhrystone Benchmark, Version 2.0 (Language: C)\n");
1727 -281c283
1728 -< /******************/
1729 ----
1730 -> /**********************/
1731 -338c340
1732 -< /******************/
1733 ----
1734 -> /**********************/
1735 -347a350,351
1736 -> else /* not executed */
1737 -> Int_Glob = 100;
1738 -349a354
1739 ->
1740 -7c7
1741 -< * Version: C, Version 2.1
1742 ----
1743 -> * Version: C, Version 2.0
1744 -9c9
1745 -< * File: dhry_2.c (part 3 of 3)
1746 ----
1747 -> * File: dhry_pack_2.c (part 3 of 3)
1748 -11c11
1749 -< * Date: May 25, 1988
1750 ----
1751 -> * Date: March 3, 1988
1752 -18c18
1753 -< #include "dhry.h"
1754 ----
1755 -> #include "dhry_global.h"
1756 -189,190d188
1757 -< else /* not executed */
1758 -< return (false);
1759 //GO.SYSIN DD dhry_c.dif
1760 echo submit.frm 1>&2
1761 sed >submit.frm <<'//GO.SYSIN DD submit.frm' 's/^-//'
1762 -DHRYSTONE 2.1 BENCHMARK REPORTING FORM
1763 -MANUF:
1764 -MODEL:
1765 -PROC:
1766 -CLOCK:
1767 -OS:
1768 -OVERSION:
1769 -COMPILER:
1770 -CVERSION:
1771 -OPTIONS:
1772 -NOREG:
1773 -REG:
1774 -NOTES:
1775 -DATE:
1776 -SUBMITTER:
1777 -CODESIZE:
1778 -MAILTO: uunet!pcrat!dry2
1779 //GO.SYSIN DD submit.frm