URL
https://opencores.org/ocsvn/openrisc/openrisc/trunk
Subversion Repositories openrisc
[/] [openrisc/] [trunk/] [or1ksim/] [testsuite/] [test-code-or1k/] [dhry/] [dhry.h] - Rev 250
Go to most recent revision | Compare with Previous | Blame | View Log
/* **************************************************************************** * * "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. * * Updated January, 1997 Rick Cramer, Galileo(R) to work with * the i960jx and Galileo-5 Reference Design. * * * 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. * -DICACHEON (default: Not defined) * Adjust performace by conditionally compiling * these i960jx CACHE paramaters. * -DICACHEOFF * -DDCACHEON (default: Not defined) * -DDCACHEOFF * * NOTE: Galileo-5 Board Frequency is set to 33Mhz in the * file jx-timer.c. If the operating frequency is * changed by replacing the crystal, then this #define * must also be changed. * *************************************************************************** * * Compilation model and measurement (IMPORTANT): * * This C version of Dhrystone consists of four 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) * - jx-timer.c (containing the code to access the i960jx timer) * * The following "ground rules" apply for measurements: * - 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. * * Example Intel 960jx compile syntax for Galileo-5. * * ic960 -AJA -Tgal5 -O2 -DREG=register dhry_1.c dhry_2.c jx-timer.c * ************************************************************************** * * 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: */ #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 to most recent revision | Compare with Previous | Blame | View Log