[PATCH 7/7] benchmarks/linpack: Port to RTEMS
---
testsuites/benchmarks/linpack/Makefile.am | 6 +-
testsuites/benchmarks/linpack/init.c | 14 +-
testsuites/benchmarks/linpack/linpack-pc.c | 211 ++---
testsuites/benchmarks/linpack/linpack.scn | 52 +++
4 files changed, 105 insertions(+), 178 deletions(-)
diff --git a/testsuites/benchmarks/linpack/Makefile.am
b/testsuites/benchmarks/linpack/Makefile.am
index d947cd6..2f5c25c 100644
--- a/testsuites/benchmarks/linpack/Makefile.am
+++ b/testsuites/benchmarks/linpack/Makefile.am
@@ -1,5 +1,6 @@
rtems_tests_PROGRAMS = linpack
-linpack_SOURCES = init.c
+linpack_SOURCES = init.c linpack-pc.c
+linpack_LDADD = -lm
dist_rtems_tests_DATA = linpack.scn linpack.doc
@@ -8,8 +9,9 @@ include $(top_srcdir)/../automake/compile.am
include $(top_srcdir)/../automake/leaf.am
AM_CPPFLAGS += -I$(top_srcdir)/../support/include
+AM_CFLAGS += -fno-inline -fno-builtin
-LINK_OBJS = $(linpack_OBJECTS)
+LINK_OBJS = $(linpack_OBJECTS) $(linpack_LDADD)
LINK_LIBS = $(linpack_LDLIBS)
linpack$(EXEEXT): $(linpack_OBJECTS) $(linpack_DEPENDENCIES)
diff --git a/testsuites/benchmarks/linpack/init.c
b/testsuites/benchmarks/linpack/init.c
index 8b67e52..c94314b 100644
--- a/testsuites/benchmarks/linpack/init.c
+++ b/testsuites/benchmarks/linpack/init.c
@@ -20,15 +20,19 @@
const char rtems_test_name[] = "LINPACK";
-static void test(void)
-{
-}
+int main(int argc, char **argv);
static void Init(rtems_task_argument arg)
{
+ char *argv[] = {
+"linpack",
+"10",
+NULL
+ };
+
TEST_BEGIN();
- test();
+ main(2, argv);
TEST_END();
rtems_test_exit(0);
@@ -41,6 +45,8 @@ static void Init(rtems_task_argument arg)
#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
+#define CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_FLOATING_POINT
+
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
#define CONFIGURE_INIT
diff --git a/testsuites/benchmarks/linpack/linpack-pc.c
b/testsuites/benchmarks/linpack/linpack-pc.c
index a5e6869..5b8bc1c 100644
--- a/testsuites/benchmarks/linpack/linpack-pc.c
+++ b/testsuites/benchmarks/linpack/linpack-pc.c
@@ -193,6 +193,8 @@
***
*/
+#define DP
+#define ROLL
#ifdef SP
#define REAL float
@@ -216,17 +218,14 @@
#endif
-#define NTIMES 10
+#define NTIMES atoi(argv[1])
#include
#include
-#include
#include
static REAL atime[9][15];
-static char this_month;
-static int this_year;
void print_time (int row);
void matgen (REAL a[], int lda, int n, REAL b[], REAL *norma);
@@ -240,56 +239,25 @@ void dscal (int n, REAL da, REAL dx[], int incx);
REAL ddot (int n, REAL dx[], int incx, REAL dy[], int incy);
/* TIME TIME TIME TIME TIME TIME TIME TIME TIME TIME TIME TIME TIME */
- #include /* for following time functions only */
- REAL second()
+ #include /* for following time functions only */
+ static REAL second(void)
{
-REAL secs;
-clock_t Time;
-Time = clock();
-secs = (REAL)Time / (REAL)CLOCKS_PER_SEC;
-return secs ;
- }
+struct timeval tv;
-/* DATE DATE DATE DATE DATE DATE DATE DATE DATE DATE DATE DATE DATE */
- #include/* for following date functions only */
- void what_date()
- {
- /* Watcom */
- struct dosdate_t adate;
- _dos_getdate( &adate );
- this_month = adate.month;
- this_year = adate.year;
-
- /* Borland
- struct date adate;
- getdate( &adate );
- this_month = adate.da_mon;
- this_year = adate.da_year;
- */
- return;
+gettimeofday(&tv, NULL);
+return (double)tv.tv_sec + (double)tv.tv_usec * 1e-6;
}
-
-main ()
+int main (int argc, char **argv)
{
static REAL aa[200*200],a[200*201],b[200],x[200];
REAL cray,ops,total,norma,normx;
REAL resid,residn,eps,t1,tm2,epsn,x1,x2;
REAL mflops;
static int ipvt[200],n,i,j,ntimes,info,lda,ldaa;
-int Endit, pass, loop;
+int pass, loop;
REAL overhead1, overhead2, time1, time2;
-FILE*outfile;
-char *compiler, *options, general[9][80] = {" "};
-
-outfile = fopen("Linpack.txt","a+");
-if (outfile == NULL)
-{
-printf ("Cannot open results file \n\n");
-printf("Press any key\n");
-Endit = getch();
-exit (0);
-}
+char *compiler, *options;
/
* Enter details of compiler and options used *
@@ -350,10 +318,10 @@ main ()
(double)residn, (double)resid, (double)epsn,
(double)x1, (double)x2);
-fprintf(stderr,"Times are reported for matrices of order
%5d\n",n);
-fprintf(stderr,"1 pass times for array with leading dime
[PATCH 2/7] benchmarks/dhrystone: Import
Import dhrystone sources from: http://www.netlib.org/benchmark/dhry-c --- testsuites/benchmarks/dhrystone/RATIONALE | 361 testsuites/benchmarks/dhrystone/README_C | 78 ++ testsuites/benchmarks/dhrystone/VARIATIONS | 157 +++ testsuites/benchmarks/dhrystone/dhry.h | 423 + testsuites/benchmarks/dhrystone/dhry_1.c | 385 ++ testsuites/benchmarks/dhrystone/dhry_2.c | 192 + 6 files changed, 1596 insertions(+) create mode 100644 testsuites/benchmarks/dhrystone/RATIONALE create mode 100644 testsuites/benchmarks/dhrystone/README_C create mode 100644 testsuites/benchmarks/dhrystone/VARIATIONS create mode 100644 testsuites/benchmarks/dhrystone/dhry.h create mode 100644 testsuites/benchmarks/dhrystone/dhry_1.c create mode 100644 testsuites/benchmarks/dhrystone/dhry_2.c diff --git a/testsuites/benchmarks/dhrystone/RATIONALE b/testsuites/benchmarks/dhrystone/RATIONALE new file mode 100644 index 000..926e046 --- /dev/null +++ b/testsuites/benchmarks/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
[PATCH 1/7] benchmarks: Add benchmark templates
--- testsuites/benchmarks/Makefile.am | 9 + testsuites/benchmarks/configure.ac| 29 testsuites/benchmarks/dhrystone/Makefile.am | 19 +++ testsuites/benchmarks/dhrystone/dhrystone.doc | 11 ++ testsuites/benchmarks/dhrystone/dhrystone.scn | 0 testsuites/benchmarks/dhrystone/init.c| 48 +++ testsuites/benchmarks/linpack/Makefile.am | 19 +++ testsuites/benchmarks/linpack/init.c | 48 +++ testsuites/benchmarks/linpack/linpack.doc | 11 ++ testsuites/benchmarks/linpack/linpack.scn | 0 testsuites/benchmarks/whetstone/Makefile.am | 19 +++ testsuites/benchmarks/whetstone/init.c| 48 +++ testsuites/benchmarks/whetstone/whetstone.doc | 11 ++ testsuites/benchmarks/whetstone/whetstone.scn | 0 testsuites/configure.ac | 2 +- 15 files changed, 273 insertions(+), 1 deletion(-) create mode 100644 testsuites/benchmarks/Makefile.am create mode 100644 testsuites/benchmarks/configure.ac create mode 100644 testsuites/benchmarks/dhrystone/Makefile.am create mode 100644 testsuites/benchmarks/dhrystone/dhrystone.doc create mode 100644 testsuites/benchmarks/dhrystone/dhrystone.scn create mode 100644 testsuites/benchmarks/dhrystone/init.c create mode 100644 testsuites/benchmarks/linpack/Makefile.am create mode 100644 testsuites/benchmarks/linpack/init.c create mode 100644 testsuites/benchmarks/linpack/linpack.doc create mode 100644 testsuites/benchmarks/linpack/linpack.scn create mode 100644 testsuites/benchmarks/whetstone/Makefile.am create mode 100644 testsuites/benchmarks/whetstone/init.c create mode 100644 testsuites/benchmarks/whetstone/whetstone.doc create mode 100644 testsuites/benchmarks/whetstone/whetstone.scn diff --git a/testsuites/benchmarks/Makefile.am b/testsuites/benchmarks/Makefile.am new file mode 100644 index 000..3d95ecd --- /dev/null +++ b/testsuites/benchmarks/Makefile.am @@ -0,0 +1,9 @@ +ACLOCAL_AMFLAGS = -I ../aclocal + +SUBDIRS = +SUBDIRS += linpack +SUBDIRS += whetstone +SUBDIRS += dhrystone + +include $(top_srcdir)/../automake/subdirs.am +include $(top_srcdir)/../automake/local.am diff --git a/testsuites/benchmarks/configure.ac b/testsuites/benchmarks/configure.ac new file mode 100644 index 000..18af749 --- /dev/null +++ b/testsuites/benchmarks/configure.ac @@ -0,0 +1,29 @@ +## Process this file with autoconf to produce a configure script. + +AC_PREREQ([2.69]) +AC_INIT([rtems-c-src-tests-benchmarks],[_RTEMS_VERSION],[https://devel.rtems.org/newticket]) +AC_CONFIG_HEADER([config.h]) +RTEMS_TOP([../..],[..]) + +RTEMS_CANONICAL_TARGET_CPU + +AM_INIT_AUTOMAKE([no-define foreign 1.12.2]) +AM_MAINTAINER_MODE + +RTEMS_ENV_RTEMSBSP + +RTEMS_PROJECT_ROOT + +RTEMS_PROG_CC_FOR_TARGET + +RTEMS_CANONICALIZE_TOOLS + +RTEMS_CHECK_CUSTOM_BSP(RTEMS_BSP) + +# Explicitly list all Makefiles here +AC_CONFIG_FILES([Makefile +linpack/Makefile +whetstone/Makefile +dhrystone/Makefile +]) +AC_OUTPUT diff --git a/testsuites/benchmarks/dhrystone/Makefile.am b/testsuites/benchmarks/dhrystone/Makefile.am new file mode 100644 index 000..0354012 --- /dev/null +++ b/testsuites/benchmarks/dhrystone/Makefile.am @@ -0,0 +1,19 @@ +rtems_tests_PROGRAMS = dhrystone +dhrystone_SOURCES = init.c + +dist_rtems_tests_DATA = dhrystone.scn dhrystone.doc + +include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg +include $(top_srcdir)/../automake/compile.am +include $(top_srcdir)/../automake/leaf.am + +AM_CPPFLAGS += -I$(top_srcdir)/../support/include + +LINK_OBJS = $(dhrystone_OBJECTS) +LINK_LIBS = $(dhrystone_LDLIBS) + +dhrystone$(EXEEXT): $(dhrystone_OBJECTS) $(dhrystone_DEPENDENCIES) + @rm -f dhrystone$(EXEEXT) + $(make-exe) + +include $(top_srcdir)/../automake/local.am diff --git a/testsuites/benchmarks/dhrystone/dhrystone.doc b/testsuites/benchmarks/dhrystone/dhrystone.doc new file mode 100644 index 000..aac6f23 --- /dev/null +++ b/testsuites/benchmarks/dhrystone/dhrystone.doc @@ -0,0 +1,11 @@ +This file describes the directives and concepts tested by this test set. + +test set name: dhrystone + +directives: + + TBD + +concepts: + + TBD diff --git a/testsuites/benchmarks/dhrystone/dhrystone.scn b/testsuites/benchmarks/dhrystone/dhrystone.scn new file mode 100644 index 000..e69de29 diff --git a/testsuites/benchmarks/dhrystone/init.c b/testsuites/benchmarks/dhrystone/init.c new file mode 100644 index 000..6e339d4 --- /dev/null +++ b/testsuites/benchmarks/dhrystone/init.c @@ -0,0 +1,48 @@ +/* + * Copyright (c) 2017 embedded brains GmbH. All rights reserved. + * + * embedded brains GmbH + * Dornierstr. 4 + * 82178 Puchheim + * Germany + * + * + * The license and distribution terms for this file may be + * found in the file LICENSE in this distribution or at + * http://www.rtems.org/license/LICENSE. + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#includ
[PATCH 5/7] benchmarks/whetstone: Port to RTEMS
---
testsuites/benchmarks/whetstone/Makefile.am | 6 --
testsuites/benchmarks/whetstone/init.c| 14 ++
testsuites/benchmarks/whetstone/whetstone.c | 23 ---
testsuites/benchmarks/whetstone/whetstone.scn | 5 +
4 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/testsuites/benchmarks/whetstone/Makefile.am
b/testsuites/benchmarks/whetstone/Makefile.am
index 6146952..a325ddc 100644
--- a/testsuites/benchmarks/whetstone/Makefile.am
+++ b/testsuites/benchmarks/whetstone/Makefile.am
@@ -1,5 +1,6 @@
rtems_tests_PROGRAMS = whetstone
-whetstone_SOURCES = init.c
+whetstone_SOURCES = init.c whetstone.c
+whetstone_LDADD = -lm
dist_rtems_tests_DATA = whetstone.scn whetstone.doc
@@ -8,8 +9,9 @@ include $(top_srcdir)/../automake/compile.am
include $(top_srcdir)/../automake/leaf.am
AM_CPPFLAGS += -I$(top_srcdir)/../support/include
+AM_CFLAGS += -fno-inline -fno-builtin
-LINK_OBJS = $(whetstone_OBJECTS)
+LINK_OBJS = $(whetstone_OBJECTS) $(whetstone_LDADD)
LINK_LIBS = $(whetstone_LDLIBS)
whetstone$(EXEEXT): $(whetstone_OBJECTS) $(whetstone_DEPENDENCIES)
diff --git a/testsuites/benchmarks/whetstone/init.c
b/testsuites/benchmarks/whetstone/init.c
index 075facc..b166118 100644
--- a/testsuites/benchmarks/whetstone/init.c
+++ b/testsuites/benchmarks/whetstone/init.c
@@ -20,15 +20,19 @@
const char rtems_test_name[] = "WHETSTONE";
-static void test(void)
-{
-}
+int main(int argc, char **argv);
static void Init(rtems_task_argument arg)
{
+ char *argv[] = {
+"whetstone",
+"1",
+NULL
+ };
+
TEST_BEGIN();
- test();
+ main(2, argv);
TEST_END();
rtems_test_exit(0);
@@ -41,6 +45,8 @@ static void Init(rtems_task_argument arg)
#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
+#define CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_FLOATING_POINT
+
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
#define CONFIGURE_INIT
diff --git a/testsuites/benchmarks/whetstone/whetstone.c
b/testsuites/benchmarks/whetstone/whetstone.c
index 159a11a..aa41353 100644
--- a/testsuites/benchmarks/whetstone/whetstone.c
+++ b/testsuites/benchmarks/whetstone/whetstone.c
@@ -58,7 +58,7 @@
C**
#include
/* the following is optional depending on the timing function used */
-#include
+#include
/* map the FORTRAN math functions, etc. to the C versions */
#define DSIN sin
@@ -82,6 +82,15 @@ void P3(double X, double Y, double *Z);
double T,T1,T2,E1[5];
int J,K,L;
+static double
+Time(void)
+{
+ struct timeval tv;
+
+ gettimeofday(&tv, NULL);
+ return (double)tv.tv_sec + (double)tv.tv_usec * 1e-6;
+}
+
int
main(int argc, char *argv[])
{
@@ -94,8 +103,8 @@ main(int argc, char *argv[])
/* added for this version */
long loopstart;
- long startsec, finisec;
- float KIPS;
+ double startsec, finisec;
+ double KIPS;
int continuous;
loopstart = 1000; /* see the note about LOOP below */
@@ -120,7 +129,7 @@ C
C Start benchmark timing at this point.
C
*/
- startsec = time(0);
+ startsec = Time();
/*
C
@@ -355,7 +364,7 @@ C
C Stop benchmark timing at this point.
C
*/
- finisec = time(0);
+ finisec = Time();
/*
C
@@ -372,10 +381,10 @@
C
return(1);
}
- printf("Loops: %ld, Iterations: %d, Duration: %ld sec.\n",
+ printf("Loops: %ld, Iterations: %d, Duration: %f sec.\n",
LOOP, II, finisec-startsec);
- KIPS = (100.0*LOOP*II)/(float)(finisec-startsec);
+ KIPS = (100.0*LOOP*II)/(finisec-startsec);
if (KIPS >= 1000.0)
printf("C Converted Double Precision Whetstones: %.1f MIPS\n",
KIPS/1000.0);
else
diff --git a/testsuites/benchmarks/whetstone/whetstone.scn
b/testsuites/benchmarks/whetstone/whetstone.scn
index e69de29..17b066d 100644
--- a/testsuites/benchmarks/whetstone/whetstone.scn
+++ b/testsuites/benchmarks/whetstone/whetstone.scn
@@ -0,0 +1,5 @@
+*** BEGIN OF TEST WHETSTONE ***
+
+Loops: 1, Iterations: 1, Duration: 347.679499 sec.
+C Converted Double Precision Whetstones: 2.9 MIPS
+*** END OF TEST WHETSTONE ***
--
1.8.4.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/7] benchmarks/dhrystone: Port to RTEMS
---
testsuites/benchmarks/dhrystone/Makefile.am | 5 ++-
testsuites/benchmarks/dhrystone/dhry.h| 12 +-
testsuites/benchmarks/dhrystone/dhry_1.c | 31 ++
testsuites/benchmarks/dhrystone/dhry_2.c | 8 ++--
testsuites/benchmarks/dhrystone/dhrystone.scn | 62 +++
testsuites/benchmarks/dhrystone/init.c| 14 --
6 files changed, 105 insertions(+), 27 deletions(-)
diff --git a/testsuites/benchmarks/dhrystone/Makefile.am
b/testsuites/benchmarks/dhrystone/Makefile.am
index 0354012..f9443e4 100644
--- a/testsuites/benchmarks/dhrystone/Makefile.am
+++ b/testsuites/benchmarks/dhrystone/Makefile.am
@@ -1,5 +1,5 @@
rtems_tests_PROGRAMS = dhrystone
-dhrystone_SOURCES = init.c
+dhrystone_SOURCES = init.c dhry_1.c dhry_2.c
dist_rtems_tests_DATA = dhrystone.scn dhrystone.doc
@@ -7,7 +7,8 @@ include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
include $(top_srcdir)/../automake/compile.am
include $(top_srcdir)/../automake/leaf.am
-AM_CPPFLAGS += -I$(top_srcdir)/../support/include
+AM_CPPFLAGS += -I$(top_srcdir)/../support/include -DTIME
+AM_CFLAGS += -fno-inline -fno-builtin
LINK_OBJS = $(dhrystone_OBJECTS)
LINK_LIBS = $(dhrystone_LDLIBS)
diff --git a/testsuites/benchmarks/dhrystone/dhry.h
b/testsuites/benchmarks/dhrystone/dhry.h
index 1714562..df52384 100644
--- a/testsuites/benchmarks/dhrystone/dhry.h
+++ b/testsuites/benchmarks/dhrystone/dhry.h
@@ -420,4 +420,14 @@ typedef struct record
} variant;
} Rec_Type, *Rec_Pointer;
-
+void Proc_1 (Rec_Pointer);
+void Proc_2 (One_Fifty *);
+void Proc_3 (Rec_Pointer *);
+void Proc_4 (void);
+void Proc_5 (void);
+void Proc_6 (Enumeration, Enumeration *);
+void Proc_7 (One_Fifty, One_Fifty, One_Fifty *);
+void Proc_8 (Arr_1_Dim, Arr_2_Dim, int, int);
+Enumeration Func_1 (Capital_Letter, Capital_Letter);
+Boolean Func_2 (Str_30, Str_30);
+Boolean Func_3 (Enumeration);
diff --git a/testsuites/benchmarks/dhrystone/dhry_1.c
b/testsuites/benchmarks/dhrystone/dhry_1.c
index 7ab02a8..7370bb0 100644
--- a/testsuites/benchmarks/dhrystone/dhry_1.c
+++ b/testsuites/benchmarks/dhrystone/dhry_1.c
@@ -17,6 +17,9 @@
#include "dhry.h"
+#include
+#include
+
/* Global Variables: */
Rec_Pointer Ptr_Glob,
@@ -28,10 +31,6 @@ charCh_1_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
@@ -51,7 +50,7 @@ extern int times ();
/* Measurements should last at least about 2 seconds */
#endif
#ifdef TIME
-extern long time();
+#include
/* see library function "time" */
#define Too_Small_Time 2
/* Measurements should last at least 2 seconds */
@@ -66,7 +65,7 @@ float Microseconds,
/* end of variables for time measurement */
-main ()
+int main (int argc, char **argv)
/*/
/* main program, corresponds to procedures*/
@@ -114,13 +113,11 @@ main ()
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;
+
+ Number_Of_Runs = atoi(argv[1]);
+ if (Number_Of_Runs < 1) {
+return 1;
}
- printf ("\n");
printf ("Execution starts, %d runs through Dhrystone\n", Number_Of_Runs);
@@ -277,7 +274,7 @@ main ()
}
-Proc_1 (Ptr_Val_Par)
+void Proc_1 (Ptr_Val_Par)
/**/
REG Rec_Pointer Ptr_Val_Par;
@@ -311,7 +308,7 @@ REG Rec_Pointer Ptr_Val_Par;
} /* Proc_1 */
-Proc_2 (Int_Par_Ref)
+void Proc_2 (Int_Par_Ref)
/**/
/* executed once */
/* *Int_Par_Ref == 1, becomes 4 */
@@ -334,7 +331,7 @@ One_Fifty *Int_Par_Ref;
} /* Proc_2 */
-Proc_3 (Ptr_Ref_Par)
+void Proc_3 (Ptr_Ref_Par)
/**/
/* executed once */
/* Ptr_Ref_Par becomes Ptr_Glob */
@@ -349,7 +346,7 @@ Rec_Pointer *Ptr_Ref_Par;
} /* Proc_3 */
-Proc_4 () /* without parameters */
+void Proc_4 (void) /* without parameters */
/***/
/* executed once */
{
@@ -361,7 +358,7 @@ Proc_4 () /* without parameters */
} /* Proc_4 */
-Proc_5 () /* without parameters */
+void Proc_5 (void) /* without parameters */
/***/
/* executed once */
{
diff --git a/testsuites/benchmarks/dhrystone/dhry_2.c
b/testsuites/benchmarks/dhrystone/dhry_2.c
index 63a3d3e..94a72eb 100644
--- a/testsuites/benchmarks/dhrystone/dhry_2.c
+++ b/testsuites/benchmarks/dhrystone/dhry_2.c
@@ -17,6 +17,8 @@
#include "dhry.h"
+#include
+
#ifndef REG
#define REG
/* REG becomes defined as empty */
@@ -27,7 +29,7 @@ extern int Int_Glob;
extern charCh_1_Glob;
-Proc_6 (Enum_Val_Par, Enum_Ref_Par)
+void Proc_6 (Enum_Val_Par, Enum_Ref_Par)
/
[PATCH 4/7] benchmarks/whetstone: Import
Import whetstone sources from:
http://www.netlib.org/benchmark/whetstone.c
---
testsuites/benchmarks/whetstone/whetstone.c | 433
1 file changed, 433 insertions(+)
create mode 100644 testsuites/benchmarks/whetstone/whetstone.c
diff --git a/testsuites/benchmarks/whetstone/whetstone.c
b/testsuites/benchmarks/whetstone/whetstone.c
new file mode 100644
index 000..159a11a
--- /dev/null
+++ b/testsuites/benchmarks/whetstone/whetstone.c
@@ -0,0 +1,433 @@
+/*
+ * C Converted Whetstone Double Precision Benchmark
+ * Version 1.2 22 March 1998
+ *
+ * (c) Copyright 1998 Painter Engineering, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is granted to use, duplicate, and
+ * publish this text and program as long as it
+ * includes this entire comment block and limited
+ * rights reference.
+ *
+ * Converted by Rich Painter, Painter Engineering, Inc. based on the
+ * www.netlib.org benchmark/whetstoned version obtained 16 March 1998.
+ *
+ * A novel approach was used here to keep the look and feel of the
+ * FORTRAN version. Altering the FORTRAN-based array indices,
+ * starting at element 1, to start at element 0 for C, would require
+ * numerous changes, including decrementing the variable indices by 1.
+ * Instead, the array E1[] was declared 1 element larger in C. This
+ * allows the FORTRAN index range to function without any literal or
+ * variable indices changes. The array element E1[0] is simply never
+ * used and does not alter the benchmark results.
+ *
+ * The major FORTRAN comment blocks were retained to minimize
+ * differences between versions. Modules N5 and N12, like in the
+ * FORTRAN version, have been eliminated here.
+ *
+ * An optional command-line argument has been provided [-c] to
+ * offer continuous repetition of the entire benchmark.
+ * An optional argument for setting an alternate LOOP count is also
+ * provided. Define PRINTOUT to cause the POUT() function to print
+ * outputs at various stages. Final timing measurements should be
+ * made with the PRINTOUT undefined.
+ *
+ * Questions and comments may be directed to the author at
+ * r.pain...@ieee.org
+ */
+/*
+C**
+C Benchmark #2 -- Double Precision Whetstone (A001)
+C
+C oThis is a REAL*8 version of
+C the Whetstone benchmark program.
+C
+C oDO-loop semantics are ANSI-66 compatible.
+C
+C oFinal measurements are to be made with all
+C WRITE statements and FORMAT sttements removed.
+C
+C**
+*/
+
+/* standard C library headers required */
+#include
+#include
+#include
+#include
+
+/* the following is optional depending on the timing function used */
+#include
+
+/* map the FORTRAN math functions, etc. to the C versions */
+#define DSIN sin
+#define DCOS cos
+#define DATAN atan
+#define DLOG log
+#define DEXP exp
+#define DSQRT sqrt
+#define IF if
+
+/* function prototypes */
+void POUT(long N, long J, long K, double X1, double X2, double X3, double X4);
+void PA(double E[]);
+void P0(void);
+void P3(double X, double Y, double *Z);
+#define USAGE "usage: whetdc [-c] [loops]\n"
+
+/*
+ COMMON T,T1,T2,E1(4),J,K,L
+*/
+double T,T1,T2,E1[5];
+int J,K,L;
+
+int
+main(int argc, char *argv[])
+{
+ /* used in the FORTRAN version */
+ long I;
+ long N1, N2, N3, N4, N6, N7, N8, N9, N10, N11;
+ double X1,X2,X3,X4,X,Y,Z;
+ long LOOP;
+ int II, JJ;
+
+ /* added for this version */
+ long loopstart;
+ long startsec, finisec;
+ float KIPS;
+ int continuous;
+
+ loopstart = 1000; /* see the note about LOOP below */
+ continuous = 0;
+
+ II = 1; /* start at the first arg (temp use of II here) */
+ while (II < argc) {
+ if (strncmp(argv[II], "-c", 2) == 0 || argv[II][0] == 'c') {
+ continuous = 1;
+ } else if (atol(argv[II]) > 0) {
+ loopstart = atol(argv[II]);
+ } else {
+ fprintf(stderr, USAGE);
+ return(1);
+ }
+ II++;
+ }
+
+LCONT:
+/*
+C
+C Start benchmark timing at this point.
+C
+*/
+ startsec = time(0);
+
+/*
+C
+C The actual benchmark starts here.
+C
+*/
+ T = .499975;
+ T1 = 0.50025;
+ T2 = 2.0;
+/*
+C
+C With loopcount LOOP=10, one million Whetstone instructions
+C will be executed in EACH MAJOR LOOP..A MAJOR LOOP IS EXECUTED
+C 'II' TIMES TO INCREASE WALL-CLOCK TIMING ACCURACY.
+C
+ LOOP = 1000;
+*/
+ LOOP = loopstart;
+ II = 1;
+
+ JJ = 1;
+
+IILOOP:
+ N1 = 0;
+ N2 = 12 * LOOP;
+ N3 = 14 * LOOP;
+ N4 = 345 *
[PATCH 6/7] benchmarks/linpack: Import
Import linpack sources from: http://www.netlib.org/benchmark/linpack-pc.c --- testsuites/benchmarks/linpack/linpack-pc.c | 1333 1 file changed, 1333 insertions(+) create mode 100644 testsuites/benchmarks/linpack/linpack-pc.c diff --git a/testsuites/benchmarks/linpack/linpack-pc.c b/testsuites/benchmarks/linpack/linpack-pc.c new file mode 100644 index 000..a5e6869 --- /dev/null +++ b/testsuites/benchmarks/linpack/linpack-pc.c @@ -0,0 +1,1333 @@ +/* + * Linpack 100x100 Benchmark In C/C++ For PCs + * + + * + * Original Source from NETLIB + * + * Translated to C by Bonnie Toy 5/88 (modified on 2/25/94 to fix + * a problem with daxpy for unequal increments or equal increments + * not equal to 1. Jack Dongarra) + * + * To obtain rolled source BLAS, add -DROLL to the command lines. + * To obtain unrolled source BLAS, add -DUNROLL to the command lines. + * + * You must specify one of -DSP or -DDP to compile correctly. + * + * You must specify one of -DROLL or -DUNROLL to compile correctly. + * + + * + * Changes in this version + * + * 1. Function prototypes are declared and function headers have + * embedded parameter types to produce code for C and C++ + * + * 2. Arrays aa and a are declared as [200*200] and [200*201] to + * allow compilation with prototypes. + * + * 3. Function second changed (compiler dependent). + * + * 4. Timing method changed due to inaccuracy of PC clock (see below). + * + * 5. Additional date function included (compiler dependent). + * + * 6. Additional code used as a standard for a series of benchmarks:- + * Automatic run time calibration rather than fixed parameters + * Initial calibration with display to show linearity + * Results displayed at reasonable rate for viewing (5 seconds) + * Facilities for typing in details of system used etc. + * Compiler details in code in case .exe files used elsewhere + * Results appended to a text file (Linpack.txt) + * + * Roy Longbottom 101323.2...@compuserve.com14 September 1996 + * + + * + * Timing + * + * The PC timer is updated at about 18 times per second or resolution of + * 0.05 to 0.06 seconds which is similar to the time taken by the main + * time consuming function dgefa on a 100 MHz Pentium. Thus there is no + * point in running the dgefa/dges1 combination three times as in the + * original version. Main timing for the latter, in the loop run NTIMES, + * executes matgen/dgefa, summing the time taken by matgen within the + * loop for later deduction from the total time. On a modern PC this sum + * can be based on a random selection of 0 or 0.05/0.06. This version + * executes the single pass once and the main timing loop five times, + * calculating the matgen overhead separately. + * + * + * + *Example of Output + * + * Rolled Double Precision Linpack Benchmark - PC Version in 'C/C++' + * + * Compiler Watcom C/C++ 10.5 Win 386 + * Optimisation -zp4 -otexan -fp5 -5r -dDP -dROLL + * + * + * norm resid resid machep x[0]-1 x[n-1]-1 + * 0.4 7.41628980e-014 1.e-015 -1.49880108e-014 -1.89848137e-014 + * + * + * Times are reported for matrices of order 100 + * 1 pass times for array with leading dimension of 201 + * + * dgefa dgesl total Mflops unit ratio + * 0.060000.00.06000 11.44 0.1748 1.0714 + * + * + * Calculating matgen overhead + * + * 10 times 0.11 seconds + * 20 times 0.22 seconds + * 40 times 0.44 seconds + * 80 times 0.87 seconds + * 160 times 1.76 seconds + * 320 times 3.52 seconds + * 640 times 7.03 seconds + * + * Overhead for 1 matgen 0.01098 seconds + * + * + * Calculating matgen/dgefa passes for 5 seconds + * + * 10 times 0.71 seconds + * 20 times 1.38 seconds + * 40 times 2.80 seconds + * 80 times 5.66 seconds + * + * Passes used 70 + * + * This is followed by output of the normal data for dgefa, dges1, + * total, Mflops, unit and ratio with five sets of results for each. + * + + * + *Example from output file Linpack.txt + * + * LINPACK BENCHMARK FOR PCs 'C/C++'n @ 100 + * + * Month run 9/1996 + * PC model Escom + * CPU Pentium + * Clock MHz 100 + * Cache 256K + * Options Neptune chipset + * OS/DOSWindows 95 + * Compiler Watcom C/C++ 10.5 Win 386 + * OptLevel
[GSOC] -- Testing Improvements Project
Hi all, My name is Andy MacGregor, I'm a 3rd year Computer Engineering student from the University of Massachusetts, Lowell (currently studying at Czech Technical University in Prague), and I'm interested in working with RTEMS for GSOC 2017. I have some experience writing unit tests for embedded systems, so I'm interested in the testing tasks like #2918(https://devel.rtems.org/ticket/2918#no1) or #2920 (https://devel.rtems.org/ticket/2920). I've read Cillian O’Donnell's GSOC proposal and Amar Takhar's vision for the direction he wants to take RTEMS testing. I see two sort of options for myself to fit into this plan. 1) I could collaborate with Cillian to convert a larger portion of the test suite 2) Or I could focus on approaching 100% code coverage for several targets. From my perspective it seems more productive to first convert the test-suite to Unity style testing first before adding test cases. Any thoughts or suggestions? Thanks for your attention, -Andy MacGregor ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [GSOC] -- Testing Improvements Project
On Tue, Mar 28, 2017 at 10:40 AM, Andy MacGregor wrote: > Hi all, > > My name is Andy MacGregor, I'm a 3rd year Computer Engineering student from > the University of Massachusetts, Lowell (currently studying at Czech > Technical University in Prague), and I'm interested in working with RTEMS > for GSOC 2017. > Hello and welcome. > I have some experience writing unit tests for embedded systems, so I'm > interested in the testing tasks like > #2918(https://devel.rtems.org/ticket/2918#no1) or #2920 > (https://devel.rtems.org/ticket/2920). > > I've read Cillian O’Donnell's GSOC proposal and Amar Takhar's vision for the > direction he wants to take RTEMS testing. > I see two sort of options for myself to fit into this plan. > 1) I could collaborate with Cillian to convert a larger portion of the test > suite > 2) Or I could focus on approaching 100% code coverage for several targets. > > From my perspective it seems more productive to first convert the test-suite > to Unity style testing first before adding test cases. Any thoughts or > suggestions? > The main thing to avoid is any dependency between you and another student. If you can both work productively and create new code in parallel, then #1 can work out. But if it requires close interaction to work, and there is a chance one student causes a bottleneck for another, then there can be some concern. I'm not sure that I've seen a clear requirements statement for the testing framework to understand what is actually needed, and what will be provided. (I'll have to read Cillian's proposal, I haven't read any of them since late last week.) For #2, there is always room for improving our code coverage, and not all of this work means writing new tests. In some cases, it means analyzing the code for problems such as dead blocks or understanding why branches are not taken. In general, we are not opposed to have "clusters" of students working on similar-themed projects. The only real blocker is if there is potential for a strict dependency to occur, where one student has to wait for another. That, we need to avoid. > Thanks for your attention, > -Andy MacGregor > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: PI STATUS
Hi , I am on the verge of completing my proposal for GSoC'17 on Raspberry Pi Improvements . Any feedback on the proposal is highly appreciated. Link to the Proposal : https://docs.google.com/document/d/12IvZZJaonk4Angjdj6Mtb0I1ykYE50mBou6vWu9LJXU/edit?usp=sharing Warm Regards , Sagar Gupta Phone: +91-8368838304 On Sun, Mar 19, 2017 at 7:51 PM, Gedare Bloom wrote: > On Sat, Mar 18, 2017 at 4:59 PM, Sagar Gupta > wrote: > > Hi Gedare > > > > I was looking at the ticket #2733(Related to your SPI issues) and > potential > > project for GSoc 2017 for Raspberry Pi > > the one I find interesting is "Convert the existing SPI support to the > new > > Linux SPI API and test with SPI devices". > > > > I have gone through the wordpress bolg(https://asuolgsoc2014. > wordpress.com/) > > of André Marques to understand the SPI API developed by him as a part of > > GSoc 14,15 . I am going through his code which he commited in RTEMS > > repository in GitHub > > (https://github.com/RTEMS/rtems/commit/61e7c698a44137afbc1447ed328b14 > a0d9e55016) > > > > I have also gone through blog post of Mudit > > Jain(http://rtemsgsoc2016-mudit.blogspot.in/) also i have gone through > code > > which he commited in RTEMS repository in GitHub > > (https://github.com/RTEMS/rtems/commit/48704cdebdd40391c5ca8d8020e5a7 > 7edff37677). > > > > I have also read about how to port drivers from FreeBSD to Rtems/libBSD > as > > posted by Ragunath in his blog post > > (http://ragustechblog.blogspot.in/2015/06/porting- > driver-from-freebsd-to-rtems.html) > > . > > > > I have also read the Alan Blog > > post(http://alanstechnotes.blogspot.in/2013/04/setting- > up-rtems-development.html) > > on how to compile GCC and RTEMS for arms and I am trying to get that > running > > on my system . I will share the results as soon as I finish with the > > community. > > > Alan's blog post may be outdated by now. > > > > > For the project the API which is refered to is that André Marques > developed > > ? > > What is the new Linux here been refered to? > The Linux API is defined under cpukit/dev > > > Can you please tell me the basic structue of what is to be implemented as > > the part for this project. > > > I don't know which BSP already implements one, but you can probably > search for an include of dev/spi.h in the libbsp to figure that out. > > > > > On Mon, Mar 6, 2017 at 6:17 PM, Gedare Bloom wrote: > >> > >> On Sun, Mar 5, 2017 at 12:24 PM, Alan Cudmore > >> wrote: > >> > Hi everyone, > >> > This is how far I was able to get when trying to run libBSD on the > Pi. I > >> > will give you a better idea of where to start. > >> > https://lists.rtems.org/pipermail/devel/2016-September/016092.html > >> > Since then, the libbsd version has been updated in RTEMS, so it may > need > >> > some work to get it to compile again. > >> > > >> > Here is a general status as I understand it: > >> > RTEMS ( without bsdlib ) works on the original Pi model B, Pi A+, Pi > B+, > >> > Pi > >> > Zero, and the Pi 2. > >> > SMP works on the Pi 2. > >> > > >> > RTEMS does not work on the Pi 3 yet, The UART that the current BSPs > use > >> > as a > >> > console is now used by the Bluetooth. > >> > So a new UART driver has to be written for the "mini-uart" that serves > >> > as > >> > the console on the Pi3. > >> > I believe the same applies to the new Raspberry Pi Zero W, which has > the > >> > same Bluetooth wireless stack. > >> > > >> > > >> > We have been working on I2C, SPI, and GPIO support. > >> > I2C has been converted to the new linux user API, but SPI has not. > >> > GPIO and I2C work, but I have not been able to get my SPI devices to > >> > work. > >> > > >> > So potential Raspberry Pi work includes: > >> > Convert the existing SPI support to the new Linux SPI API and test > with > >> > SPI > >> > devices > >> > Continue to work on the LibBSD support > >> > Support the Pi Zero W ( and potentially the Pi 3 ) by creating a new > >> > uart > >> > driver > >> > Support Pi 3 SMP ( along with the UART ) > >> > > >> > Even more advanced work could include: > >> > Support the Wifi and bluetooth in LibBSD for the Pi Zero W and/or Pi > 3. > >> > > >> > Gedare, I know this should probably be on the GSOC wiki, right ? > >> > > >> > >> I added to the relevant open project ticket: > >> https://devel.rtems.org/ticket/2899 > >> > >> Related to your SPI issues may be: https://devel.rtems.org/ticket/2733 > >> > >> > Alan > >> > > >> > > >> > On Sun, Mar 5, 2017 at 7:49 AM, Gedare Bloom > wrote: > >> >> > >> >> Hello Sagar Gupta, > >> >> > >> >> The best place to start is with the previous GSoC effort that focused > >> >> on Raspberry PI. This was last year's project > >> >> https://devel.rtems.org/wiki/GSoC/2016/USB%26EthernetRaspberryPi > >> >> > >> >> > >> >> > >> >> On Sat, Mar 4, 2017 at 2:21 AM, Sagar Gupta > >> >> wrote: > >> >> > Hi , > >> >> > > >> >> > I have done a course on Operating Systems at undergraduate level. > >> >> > I am specifically interested in development o
Re: [GSOC] -- Testing Improvements Project
On 2017-03-28 12:43 -0400, Gedare Bloom wrote: > The main thing to avoid is any dependency between you and another > student. If you can both work productively and create new code in > parallel, then #1 can work out. But if it requires close interaction > to work, and there is a chance one student causes a bottleneck for > another, then there can be some concern. This can work and I have done it for other projects in the past. What needs to happen is the two students need to work on completely separate areas where there is no overlap or dependencies. I can say up-front that the students applying so far lack the knowledge in C to do the more advanced tests. At this point I have received two proposals on doing this work. > I'm not sure that I've seen a clear requirements statement for the > testing framework to understand what is actually needed, and what will > be provided. (I'll have to read Cillian's proposal, I haven't read any > of them since late last week.) I am working with Cillian now to firm up their proposal and give an introduction to the test suite. At the moment we are trying to gauge their abilities to see what areas are suited for them to work on. > For #2, there is always room for improving our code coverage, and not > all of this work means writing new tests. In some cases, it means > analyzing the code for problems such as dead blocks or understanding > why branches are not taken. Agreed. Most of this work does not involve writing new tests but there will be some required. > In general, we are not opposed to have "clusters" of students working > on similar-themed projects. The only real blocker is if there is > potential for a strict dependency to occur, where one student has to > wait for another. That, we need to avoid. It's only possible to avoid dependencies between the two if they have vastly different abilities with C. Feel free to email me directly to discuss. Amar. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
