操作系统课程的实验答案和报告.zip

/****************** "DHRYSTONE" Benchmark Program ***************************/ #define Version "C, Version 2.2" /* File: dhry_1.c (part 2 of 3) * Author: Reinhold P. Weicker * Siemens Nixdorf, Paderborn/Germany * weicker@specbench.org * Date: May 25, 1988 * Modified: Steven Pemberton, CWI, Amsterdam; Steven.Pemberton@cwi.nl * Date: October, 1993; March 1995 * Included both files into one source, that gets compiled * in two passes. Made program auto-compiling, and auto-running, * and generally made it much easier to use. * * 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. * *************************************************************************** * * Defines: The following "Defines" are possible: * -DREG (default: Not defined) * As an approximation to what an average C programmer * might do, causes the "register" storage class to be applied * - 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. * *************************************************************************** * * History: Version C/2.1 was made for two reasons: * * 1) There was 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 i