diff options
Diffstat (limited to 'zpu/roadshow/roadshow/dhrystone')
-rw-r--r-- | zpu/roadshow/roadshow/dhrystone/.cvsignore | 2 | ||||
-rw-r--r-- | zpu/roadshow/roadshow/dhrystone/RATIONALE | 361 | ||||
-rw-r--r-- | zpu/roadshow/roadshow/dhrystone/README_C | 78 | ||||
-rw-r--r-- | zpu/roadshow/roadshow/dhrystone/VARIATIONS | 157 | ||||
-rw-r--r-- | zpu/roadshow/roadshow/dhrystone/build.sh | 7 | ||||
-rw-r--r-- | zpu/roadshow/roadshow/dhrystone/dhry-c | 1779 | ||||
-rw-r--r-- | zpu/roadshow/roadshow/dhrystone/dhry.h | 423 | ||||
-rw-r--r-- | zpu/roadshow/roadshow/dhrystone/dhry_1.c | 533 | ||||
-rw-r--r-- | zpu/roadshow/roadshow/dhrystone/dhry_2.c | 192 | ||||
-rw-r--r-- | zpu/roadshow/roadshow/dhrystone/dhry_c.dif | 141 | ||||
-rw-r--r-- | zpu/roadshow/roadshow/dhrystone/dhrystone.bin | bin | 0 -> 13028 bytes | |||
-rw-r--r-- | zpu/roadshow/roadshow/dhrystone/dhrystone.zpu | bin | 0 -> 13069 bytes | |||
-rw-r--r-- | zpu/roadshow/roadshow/dhrystone/submit.frm | 17 |
13 files changed, 3690 insertions, 0 deletions
diff --git a/zpu/roadshow/roadshow/dhrystone/.cvsignore b/zpu/roadshow/roadshow/dhrystone/.cvsignore new file mode 100644 index 0000000..3544c3f --- /dev/null +++ b/zpu/roadshow/roadshow/dhrystone/.cvsignore @@ -0,0 +1,2 @@ +dhrystone.elf +dhrystone_zpu.elf diff --git a/zpu/roadshow/roadshow/dhrystone/RATIONALE b/zpu/roadshow/roadshow/dhrystone/RATIONALE new file mode 100644 index 0000000..926e046 --- /dev/null +++ b/zpu/roadshow/roadshow/dhrystone/RATIONALE @@ -0,0 +1,361 @@ + + + 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 + diff --git a/zpu/roadshow/roadshow/dhrystone/README_C b/zpu/roadshow/roadshow/dhrystone/README_C new file mode 100644 index 0000000..a27a192 --- /dev/null +++ b/zpu/roadshow/roadshow/dhrystone/README_C @@ -0,0 +1,78 @@ +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 diff --git a/zpu/roadshow/roadshow/dhrystone/VARIATIONS b/zpu/roadshow/roadshow/dhrystone/VARIATIONS new file mode 100644 index 0000000..3046cbd --- /dev/null +++ b/zpu/roadshow/roadshow/dhrystone/VARIATIONS @@ -0,0 +1,157 @@ + + 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. + diff --git a/zpu/roadshow/roadshow/dhrystone/build.sh b/zpu/roadshow/roadshow/dhrystone/build.sh new file mode 100644 index 0000000..5bba707 --- /dev/null +++ b/zpu/roadshow/roadshow/dhrystone/build.sh @@ -0,0 +1,7 @@ +zpu-elf-gcc -phi -DTIME dhry_1.c dhry_2.c -O3 -Wl,--relax -Wl,--gc-sections -o dhrystone.elf +zpu-elf-size *.elf +zpu-elf-objcopy -O binary dhrystone.elf dhrystone.bin +sh ../build/makefirmware.sh dhrystone.bin dhrystone.zpu + + + diff --git a/zpu/roadshow/roadshow/dhrystone/dhry-c b/zpu/roadshow/roadshow/dhrystone/dhry-c new file mode 100644 index 0000000..4cec46c --- /dev/null +++ b/zpu/roadshow/roadshow/dhrystone/dhry-c @@ -0,0 +1,1779 @@ +# 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 diff --git a/zpu/roadshow/roadshow/dhrystone/dhry.h b/zpu/roadshow/roadshow/dhrystone/dhry.h new file mode 100644 index 0000000..211c2e2 --- /dev/null +++ b/zpu/roadshow/roadshow/dhrystone/dhry.h @@ -0,0 +1,423 @@ +/*
+ ****************************************************************************
+ *
+ * "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
+ /* 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;
+
+
diff --git a/zpu/roadshow/roadshow/dhrystone/dhry_1.c b/zpu/roadshow/roadshow/dhrystone/dhry_1.c new file mode 100644 index 0000000..08a29b9 --- /dev/null +++ b/zpu/roadshow/roadshow/dhrystone/dhry_1.c @@ -0,0 +1,533 @@ +/*
+ ****************************************************************************
+ *
+ * "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"
+#include <stdarg.h>
+
+static int
+_cvt(int val, char *buf, int radix, char *digits)
+{
+ char temp[80];
+ char *cp = temp;
+ int length = 0;
+
+ if (val == 0) {
+ /* Special case */
+ *cp++ = '0';
+ } else {
+ while (val) {
+ *cp++ = digits[val % radix];
+ val /= radix;
+ }
+ }
+ while (cp != temp) {
+ *buf++ = *--cp;
+ length++;
+ }
+ *buf = '\0';
+ return (length);
+}
+
+#define is_digit(c) ((c >= '0') && (c <= '9'))
+
+
+#ifndef TINY
+static int
+_vprintf(void (*putc)(char c, void **param), void **param, const char *fmt, va_list ap)
+{
+ char buf[sizeof(long long)*8];
+ char c, sign, *cp=buf;
+ int left_prec, right_prec, zero_fill, pad, pad_on_right,
+ i, islong, islonglong;
+ long long val = 0;
+ int res = 0, length = 0;
+
+ while ((c = *fmt++) != '\0') {
+ if (c == '%') {
+ c = *fmt++;
+ left_prec = right_prec = pad_on_right = islong = islonglong = 0;
+ sign = '\0';
+ // Fetch value [numeric descriptors only]
+ switch (c) {
+ case 'd':
+ val = (long long)va_arg(ap, int);
+ if ((c == 'd') || (c == 'D')) {
+ if (val < 0) {
+ sign = '-';
+ val = -val;
+ }
+ } else {
+ // Mask to unsigned, sized quantity
+ if (islong) {
+ val &= ((long long)1 << (sizeof(long) * 8)) - 1;
+ } else{
+ val &= ((long long)1 << (sizeof(int) * 8)) - 1;
+ }
+ }
+ break;
+ default:
+ break;
+ }
+ // Process output
+ switch (c) {
+ case 'd':
+ switch (c) {
+ case 'd':
+ length = _cvt(val, buf, 10, "0123456789");
+ break;
+ }
+ cp = buf;
+ break;
+ case 's':
+ cp = va_arg(ap, char *);
+ length = 0;
+ while (cp[length] != '\0') length++;
+ break;
+ case 'c':
+ c = va_arg(ap, int /*char*/);
+ (*putc)(c, param);
+ res++;
+ continue;
+ default:
+ (*putc)('%', param);
+ (*putc)(c, param);
+ res += 2;
+ continue;
+ }
+ while (length-- > 0) {
+ c = *cp++;
+ (*putc)(c, param);
+ res++;
+ }
+ } else {
+ (*putc)(c, param);
+ res++;
+ }
+ }
+ return (res);
+}
+#endif
+
+// Default wrapper function used by diag_printf
+static void
+_diag_write_char(char c, void **param)
+{
+ if (c=='\n')
+ {
+ outbyte('\r');
+ }
+ outbyte(c);
+}
+
+int
+small_printf(const char *fmt, ...)
+{
+#ifndef TINY
+ va_list ap;
+ int ret;
+
+ va_start(ap, fmt);
+ ret = _vprintf(_diag_write_char, (void **)0, fmt, ap);
+ va_end(ap);
+ return (ret);
+#else
+ return 0;
+#endif
+}
+
+
+
+
+/* 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];
+
+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;
+ /* 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 long Begin_Time,
+ End_Time,
+ User_Time;
+long long Microseconds,
+ Dhrystones_Per_Second,
+ Vax_Mips;
+
+/* end of variables for time measurement */
+
+int Number_Of_Runs = 50000;
+
+extern long long _readMicroseconds();
+
+
+int 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;
+
+ /* 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. */
+ small_printf ("\n");
+ small_printf ("Dhrystone Benchmark, Version 2.1 (Language: C)\n");
+ small_printf ("\n");
+ if (Reg)
+ {
+ small_printf ("Program compiled with 'register' attribute\n");
+ small_printf ("\n");
+ }
+ else
+ {
+ small_printf ("Program compiled without 'register' attribute\n");
+ small_printf ("\n");
+ }
+ Number_Of_Runs;
+
+ small_printf ("Execution starts, %d runs through Dhrystone\n", Number_Of_Runs);
+
+ /***************/
+ /* Start timer */
+ /***************/
+
+#if 0
+#ifdef TIMES
+ times (&time_info);
+ Begin_Time = (long) time_info.tms_utime;
+#endif
+#ifdef TIME
+ Begin_Time = time ( (long *) 0);
+#endif
+#else
+ Begin_Time = _readMicroseconds();
+#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 */
+ /**************/
+
+#if 0
+#ifdef TIMES
+ times (&time_info);
+ End_Time = (long) time_info.tms_utime;
+#endif
+#ifdef TIME
+ End_Time = time ( (long *) 0);
+#endif
+#else
+ End_Time = _readMicroseconds();
+#endif
+
+ small_printf ("Execution ends\n");
+ small_printf ("\n");
+ small_printf ("Final values of the variables used in the benchmark:\n");
+ small_printf ("\n");
+ small_printf ("Int_Glob: %d\n", Int_Glob);
+ small_printf (" should be: %d\n", 5);
+ small_printf ("Bool_Glob: %d\n", Bool_Glob);
+ small_printf (" should be: %d\n", 1);
+ small_printf ("Ch_1_Glob: %c\n", Ch_1_Glob);
+ small_printf (" should be: %c\n", 'A');
+ small_printf ("Ch_2_Glob: %c\n", Ch_2_Glob);
+ small_printf (" should be: %c\n", 'B');
+ small_printf ("Arr_1_Glob[8]: %d\n", Arr_1_Glob[8]);
+ small_printf (" should be: %d\n", 7);
+ small_printf ("Arr_2_Glob[8][7]: %d\n", Arr_2_Glob[8][7]);
+ small_printf (" should be: Number_Of_Runs + 10\n");
+ small_printf ("Ptr_Glob->\n");
+ small_printf (" Ptr_Comp: %d\n", (int) Ptr_Glob->Ptr_Comp);
+ small_printf (" should be: (implementation-dependent)\n");
+ small_printf (" Discr: %d\n", Ptr_Glob->Discr);
+ small_printf (" should be: %d\n", 0);
+ small_printf (" Enum_Comp: %d\n", Ptr_Glob->variant.var_1.Enum_Comp);
+ small_printf (" should be: %d\n", 2);
+ small_printf (" Int_Comp: %d\n", Ptr_Glob->variant.var_1.Int_Comp);
+ small_printf (" should be: %d\n", 17);
+ small_printf (" Str_Comp: %s\n", Ptr_Glob->variant.var_1.Str_Comp);
+ small_printf (" should be: DHRYSTONE PROGRAM, SOME STRING\n");
+ small_printf ("Next_Ptr_Glob->\n");
+ small_printf (" Ptr_Comp: %d\n", (int) Next_Ptr_Glob->Ptr_Comp);
+ small_printf (" should be: (implementation-dependent), same as above\n");
+ small_printf (" Discr: %d\n", Next_Ptr_Glob->Discr);
+ small_printf (" should be: %d\n", 0);
+ small_printf (" Enum_Comp: %d\n", Next_Ptr_Glob->variant.var_1.Enum_Comp);
+ small_printf (" should be: %d\n", 1);
+ small_printf (" Int_Comp: %d\n", Next_Ptr_Glob->variant.var_1.Int_Comp);
+ small_printf (" should be: %d\n", 18);
+ small_printf (" Str_Comp: %s\n",
+ Next_Ptr_Glob->variant.var_1.Str_Comp);
+ small_printf (" should be: DHRYSTONE PROGRAM, SOME STRING\n");
+ small_printf ("Int_1_Loc: %d\n", Int_1_Loc);
+ small_printf (" should be: %d\n", 5);
+ small_printf ("Int_2_Loc: %d\n", Int_2_Loc);
+ small_printf (" should be: %d\n", 13);
+ small_printf ("Int_3_Loc: %d\n", Int_3_Loc);
+ small_printf (" should be: %d\n", 7);
+ small_printf ("Enum_Loc: %d\n", Enum_Loc);
+ small_printf (" should be: %d\n", 1);
+ small_printf ("Str_1_Loc: %s\n", Str_1_Loc);
+ small_printf (" should be: DHRYSTONE PROGRAM, 1'ST STRING\n");
+ small_printf ("Str_2_Loc: %s\n", Str_2_Loc);
+ small_printf (" should be: DHRYSTONE PROGRAM, 2'ND STRING\n");
+ small_printf ("\n");
+
+ User_Time = End_Time - Begin_Time;
+ small_printf ("User time: %d\n", (int)User_Time);
+
+ if (User_Time < Too_Small_Time)
+ {
+ small_printf ("Measured time too small to obtain meaningful results\n");
+ small_printf ("Please increase number of runs\n");
+ small_printf ("\n");
+ }
+/* else */
+ {
+#if 0
+#ifdef TIME
+ Microseconds = (User_Time * Mic_secs_Per_Second )
+ / Number_Of_Runs;
+ Dhrystones_Per_Second = Number_Of_Runs / User_Time;
+ Vax_Mips = (Number_Of_Runs*1000) / (1757*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;
+ Vax_Mips = Dhrystones_Per_Second / 1757.0;
+#endif
+#else
+ Microseconds = User_Time / Number_Of_Runs;
+ Dhrystones_Per_Second = ((long long)Number_Of_Runs*1000000) / User_Time;
+ Vax_Mips = (((long long)Number_Of_Runs)*1000000000) / (1757*User_Time);
+#endif
+ small_printf ("Microseconds for one run through Dhrystone: ");
+ small_printf ("%d \n", (int)Microseconds);
+ small_printf ("Dhrystones per Second: ");
+ small_printf ("%d \n", (int)Dhrystones_Per_Second);
+ small_printf ("VAX MIPS rating * 1000 = %d \n",(int)Vax_Mips);
+ small_printf ("\n");
+ }
+
+ return 0;
+}
+
+
+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
+
+
diff --git a/zpu/roadshow/roadshow/dhrystone/dhry_2.c b/zpu/roadshow/roadshow/dhrystone/dhry_2.c new file mode 100644 index 0000000..ed0e5b7 --- /dev/null +++ b/zpu/roadshow/roadshow/dhrystone/dhry_2.c @@ -0,0 +1,192 @@ +/*
+ ****************************************************************************
+ *
+ * "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 */
+
diff --git a/zpu/roadshow/roadshow/dhrystone/dhry_c.dif b/zpu/roadshow/roadshow/dhrystone/dhry_c.dif new file mode 100644 index 0000000..8bcaaea --- /dev/null +++ b/zpu/roadshow/roadshow/dhrystone/dhry_c.dif @@ -0,0 +1,141 @@ +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); diff --git a/zpu/roadshow/roadshow/dhrystone/dhrystone.bin b/zpu/roadshow/roadshow/dhrystone/dhrystone.bin Binary files differnew file mode 100644 index 0000000..ee1a6fe --- /dev/null +++ b/zpu/roadshow/roadshow/dhrystone/dhrystone.bin diff --git a/zpu/roadshow/roadshow/dhrystone/dhrystone.zpu b/zpu/roadshow/roadshow/dhrystone/dhrystone.zpu Binary files differnew file mode 100644 index 0000000..e37e59f --- /dev/null +++ b/zpu/roadshow/roadshow/dhrystone/dhrystone.zpu diff --git a/zpu/roadshow/roadshow/dhrystone/submit.frm b/zpu/roadshow/roadshow/dhrystone/submit.frm new file mode 100644 index 0000000..a75a689 --- /dev/null +++ b/zpu/roadshow/roadshow/dhrystone/submit.frm @@ -0,0 +1,17 @@ +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 |