Dec 142017
A collection of C benchmark routines. Full source is included. | |||
---|---|---|---|
File Name | File Size | Zip Size | Zip Type |
ADDRMATH.C | 2108 | 452 | deflated |
CALLOVRH.C | 498 | 235 | deflated |
CPARR.C | 1276 | 452 | deflated |
DISKIO.C | 8445 | 1220 | deflated |
DISKIO.H | 559 | 294 | deflated |
DRY.C | 16835 | 4486 | deflated |
MATH.C | 2931 | 602 | deflated |
MEMREF.C | 2792 | 484 | deflated |
MKTSTFIL.C | 869 | 406 | deflated |
RANDPOS.C | 342 | 207 | deflated |
READ.ME | 4207 | 1658 | deflated |
RPT.C | 7327 | 2126 | deflated |
STRLIB.C | 1662 | 436 | deflated |
TEST1.C | 6017 | 1431 | deflated |
TESTBED.C | 5881 | 1402 | deflated |
TIMER.C | 3464 | 801 | deflated |
Download File CBENCH.ZIP Here
Contents of the READ.ME file
To whom it may concern:
On the disk i/o tests. I did my testing to a ram disk.
Additionally, I removed the buffers= line from my config.sys
because the extra layer of system buffering slowed down the "disk i/o".
Also in the area of file i/o, many of the compilers have their
own unique parameters to open (and creat) and fopen. You'll probably
have to make some adjustments in diskio, rpt and mktstfil.
The data file written by mktstfil is just one long bunch of
characters, 64000 to be exact. There are no line separators and no
nulls.
The main driver for the entire testbed is testbed.c. It
contains a data structure which controls the execution of all of the
individual test routines.
There is also a file called test1.c which I set up to run a
single test. This was useful for situations in which there was an
error and I didn't want to rerun all of the earlier tests (I ran the
disk tests a number of different ways).
To all of you guys with 68000 compilers, when I started to
put these tests together, I had no idea that a port would be in order.
Be aware that, with the exception of the drystone, this batch of code
was developed on a machine with a 16 bit int. So, if you have any
problems because your int size is too long, change the offending ints
to shorts. (Usually, the problems come in the other direction. So,
my guess is that you're ok.)
With the foregoing caveats, if you have any questions or
suggestions, or if you just want to talk, feel free to call.
Good luck.
David Kessler.
This list contains a brief description of each of the .c files. It also
groups the files into the portions of the compiler which the tests try
to exercise. I have also included the names of the individual routines
contained in each file and the description which appears on the final
report below each file name.
Miscellaneous routines:
diskio.h some constants used by the disk referencing code
(mktstfil, diskio, rpt)
testbed.c driver for the testbed routines
test1.c test one benchmark routine
randpos.c figure a file position for random seeks
timer.c timing routines
mktstfil.c make the input test file
Math:
addrmath.c address arithmetic
aacptr aa char ptr
aasptr aa struct ptr
math.c arithmetic of various types
clcint calc int
clclong calc long
clcflt calc float
clcdbl calc double
Subroutine calling overhead:
callovrh.c minimum subroutine calling overhead
calltest call overhead
Memory reference:
cparr.c copying arrays
cparr cp array
cpptr cp pointer
memref.c running loops using different data types
lpauto lp auto
lpstatic lp static
lp2regs lp 2 reg vars
lp5regs lp 5 reg vars
Disk I/O - buffered/unbuffered, ram disk:
diskio.c copy files and seek/read in different ways
fcharcpy cp f- char
charcpy cp char
fbufcpy cp f- block
bufcpy cp block
fseekio cp f- seekio
seekio cp seekio
Libraries:
strlib.c test some string library routines
lbstrlen lib strlen
lbstrcpy lib strcpy
lbstrcmp lib strcmp
Dummy applications:
dry.c drystone (dhampstone?)
dry drystone
rpt.c dummy report writer
rptcsort rpt c sort
rptshell rpt shellsort
To build testbed.exe, compile and then link appropriately:
testbed, timer, memref, addrmath, cparr, diskio,
callovrh, math, strlib, rpt, dry, randpos
To build test1.exe, compile and then link appropriately:
test1, timer, module with the routine(s) to test
To build mktstfil.exe, compile and then link appropriately:
mktstfil
On the disk i/o tests. I did my testing to a ram disk.
Additionally, I removed the buffers= line from my config.sys
because the extra layer of system buffering slowed down the "disk i/o".
Also in the area of file i/o, many of the compilers have their
own unique parameters to open (and creat) and fopen. You'll probably
have to make some adjustments in diskio, rpt and mktstfil.
The data file written by mktstfil is just one long bunch of
characters, 64000 to be exact. There are no line separators and no
nulls.
The main driver for the entire testbed is testbed.c. It
contains a data structure which controls the execution of all of the
individual test routines.
There is also a file called test1.c which I set up to run a
single test. This was useful for situations in which there was an
error and I didn't want to rerun all of the earlier tests (I ran the
disk tests a number of different ways).
To all of you guys with 68000 compilers, when I started to
put these tests together, I had no idea that a port would be in order.
Be aware that, with the exception of the drystone, this batch of code
was developed on a machine with a 16 bit int. So, if you have any
problems because your int size is too long, change the offending ints
to shorts. (Usually, the problems come in the other direction. So,
my guess is that you're ok.)
With the foregoing caveats, if you have any questions or
suggestions, or if you just want to talk, feel free to call.
Good luck.
David Kessler.
This list contains a brief description of each of the .c files. It also
groups the files into the portions of the compiler which the tests try
to exercise. I have also included the names of the individual routines
contained in each file and the description which appears on the final
report below each file name.
Miscellaneous routines:
diskio.h some constants used by the disk referencing code
(mktstfil, diskio, rpt)
testbed.c driver for the testbed routines
test1.c test one benchmark routine
randpos.c figure a file position for random seeks
timer.c timing routines
mktstfil.c make the input test file
Math:
addrmath.c address arithmetic
aacptr aa char ptr
aasptr aa struct ptr
math.c arithmetic of various types
clcint calc int
clclong calc long
clcflt calc float
clcdbl calc double
Subroutine calling overhead:
callovrh.c minimum subroutine calling overhead
calltest call overhead
Memory reference:
cparr.c copying arrays
cparr cp array
cpptr cp pointer
memref.c running loops using different data types
lpauto lp auto
lpstatic lp static
lp2regs lp 2 reg vars
lp5regs lp 5 reg vars
Disk I/O - buffered/unbuffered, ram disk:
diskio.c copy files and seek/read in different ways
fcharcpy cp f- char
charcpy cp char
fbufcpy cp f- block
bufcpy cp block
fseekio cp f- seekio
seekio cp seekio
Libraries:
strlib.c test some string library routines
lbstrlen lib strlen
lbstrcpy lib strcpy
lbstrcmp lib strcmp
Dummy applications:
dry.c drystone (dhampstone?)
dry drystone
rpt.c dummy report writer
rptcsort rpt c sort
rptshell rpt shellsort
To build testbed.exe, compile and then link appropriately:
testbed, timer, memref, addrmath, cparr, diskio,
callovrh, math, strlib, rpt, dry, randpos
To build test1.exe, compile and then link appropriately:
test1, timer, module with the routine(s) to test
To build mktstfil.exe, compile and then link appropriately:
mktstfil
December 14, 2017
Add comments