1,381
edits
Changes
no edit summary
strcpy (Str_2_Loc, "DHRYSTONE PROGRAM, 3'RD STRING");
Int_2_Loc = Run_Index;
Int_Glob = Run_Index;</pre>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.
*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.
*For Proc_2, no code has been changed, but the values of the actual parameter have changed due to changes in "main".
*In Proc_4, the second assignment has been changed from <br>
to
Bool_Glob = Bool_Loc | Bool_Glob;</pre>
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.
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.
*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.
*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<br>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). <br>
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<br>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.
*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.
*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.
*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.
[3]Brian W. Kernighan and Dennis M. Ritchie: The C Programming Language. Prentice-Hall, Englewood Cliffs (NJ) 1978
<br> = IGEP Dhrystone 2.1 MIPS Test = == Test Software == You can donwload the Dhrystone 2.1 MIPS test from [http://downloads.igep.es/files/dhrystone-2.1.tar.gz here]. The software it's compiled for OMAP / DM processors, inside exist 4 executables: *gcc_dry2 and gcc_dry2reg Tune Parameters: GCCOPTIM= -O Compiler: Linaro & Ubuntu <pre>$ arm-linux-gnueabi-gcc -vUsing built-in specs.COLLECT_GCC=arm-linux-gnueabi-gccCOLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.2/lto-wrapperTarget: arm-linux-gnueabiConfigured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.5.2 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/libThread model: posixgcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3)</pre>*cc_dry2 and cc_dry2reg Tune Parameters:<br> OPTIMIZE= -O4 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize Compiler: Linaro & Ubuntu<br><pre>$ arm-linux-gnueabi-gcc -vUsing built-in specs.COLLECT_GCC=arm-linux-gnueabi-gccCOLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.2/lto-wrapperTarget: arm-linux-gnueabiConfigured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.5.2 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/libThread model: posixgcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3)</pre> === Test Case 1: IGEPv2 Revision C === Board: IGEPv2 Revision C - RC5 - DM3730 @ 1Ghz