Compiling dhrystone with simple IDE

rwgast_logicdesign · 2012-06-06 10:06

I have tried to compile the dhrystone demo with the command line and simple IDE and get the same error everytime

Project Directory: C:/propgcc/demos/dhrystone/
Ignoring "Simple printf" flag in COG mode program.
propeller-elf-gcc.exe -o a.out -Os -mcog -I . -fno-exceptions dry.c
dry.c:415:23: fatal error: sys/times.h: No such file or directory
compilation terminated.
Done. Build Failed!
Click error messages above to debug.
Check source for bad function call or global variable name.

Anyone know what im doing wrong?? Im assuming this will just print the mips to the serial console when compiled? It would make a gret testing tool for OCing!

mindrobots · 2012-06-06 10:45

Some of the demo programs don't compile from SimpleIDE for a variety of reasons. They work with the command line version.

I currently don't have a machine with the command line version installed. Al the demos in the demo package have been tested at some point with the command line version and have working make files. You just need to instal the command line version and you should be go to go.

Testing these is a part of the release process that needs to be done....only so many resources to go around on the project.

rwgast_logicdesign · 2012-06-06 11:25

Like I said above I tried the command line too, I didnt even know about the IDE till 30mins ago. Here is the command line results with compilation as per the GCC quickStart guide.

C:\propgcc\demos\dhrystone>propeller-elf-gcc -o dry.elf dry.c
dry.c:415:23: fatal error: sys/times.h: No such file or directory
compilation terminated.

C:\propgcc\demos\dhrystone>

I set propgg in my path, then realized there was a .bat ran that and installed simpleIDE which sets the paths so Im pretty sure this isnt an issue with my paths.

mindrobots · 2012-06-06 11:33

Sorry, I missed the part about the command line.

The include file in the library is sys.time.h - I changed this but it went on to another error complaining about sys/param.h

At this point, one of the developers will need to chime in with suggestions.

I know most of the efforts have been on the IDE package, so I'm not sure if some of the original demos fell out of favor at some point and need a little bit of TLC.

jazzed · 2012-06-06 11:48

Please compile dhrystone tests with the makefile in the demo. It is a multiple pass compile.

Dave Hein · 2012-06-06 11:54

You could compile the Dhrystone app under SIDE if you make a copy of the source file and add a "#define PASS2" at the beginning of the second copy.

rwgast_logicdesign · 2012-06-06 12:01

when I use make i get an error libgcc_s_dw2-1.dll was not found. Re-Installing the aplication may fix this problem.

mindrobots · 2012-06-06 12:33

In SimpleIDE, It didn't look much better with #define PASS2 in my dry2.c but when I added #define PASS1 to dry.c also, it did much better.

Now the only problem it has is it can't find 'sys/param.h' - which doesn't seem to be in the propgcc library sources either....or any place else on my disk.

Project Directory: C:/Users/rapost/Documents/SimpleIDE/dhrystone/   propeller-elf-gcc.exe -o a.out -Os -mxmm-split -I . -Wall -fno-exceptions -Wno-unused-value dry2.c dry.c
 dry2.c:418:76: fatal error: sys/param.h: No such file or directory
 compilation terminated.
  dry.c:418:76: fatal error: sys/param.h: No such file or directory
 compilation terminated.
  Done. Build Failed!
  Click error messages above to debug.
  Check source for bad function call or global variable name.

jazzed · 2012-06-06 12:47

It is not possible to build dhrystone with SimpleIDE at all because of the way the program needs to be built - please don't bother.

Are you using the windows-i686-propgcc-v0_3_1 package?
Sorry, make for windows is not in the SimpleIDE package.

mindrobots · 2012-06-06 12:49

Ok, I'll bow down to the impossible!!

Time to instal the command line stuff so I'm fully compatible.

jazzed · 2012-06-06 12:56

mindrobots wrote: »

Ok, I'll bow down to the impossible!!
Time to instal the command line stuff so I'm fully compatible.

Please use one or the other - not both unless you put the gcc windowz zip package into another folder.

mindrobots · 2012-06-06 13:21

I love deceit and trickery.....

1) unzip the cmd line package into c:\pgcc-cmd
2) change the addpath.bat to reflect the new directory (so we don't screw up if we use it later)
3) copy my demo directory under c:\pgcc-cmd (because I'm lazy)
4) copy my modified *.cfg files from the propgcc/propeller-load directory to pgcc-cmd/propeller-load
4) change to the dhrystone directory and run make - it gave a couple warnings
5) use this propeller-load line: propeller-load.exe -b PPUSB-2 -p COM18 dry.elf -r

Watch it run!

For 100Mhz Propeller:
Microseconds for one run through Dhrystone: 114
Dhrystones per Second:                      8729

(time out to change crystals)

For 80MHz Propeller:
Microseconds for one run through Dhrystone: 143
Dhrystones per Second:                      6983

AND!! SIDE still works!!

Thanks for the afternoon distraction, guys!!!

Dave Hein · 2012-06-06 15:10

Steve,

I don't understand why the dhrystone program can't be build with SIDE. It looks like all that is needed is to copy dry.c to dry2.c and add "#define PASS2" to the beginning of dry2.c. dry.c and dry2.c should be included in the project file, and the following defines should be added to the compiler options:

-Dprintf=__simple_printf -DMSC_CLOCK -DINTEGER_ONLY -DFIXED_NUMBER_OF_PASSES=5000

The make file also includes the -O2 and -mfcache compiler options. It seems like it should work with SIDE.

Dave

jazzed · 2012-06-06 15:32

Dave Hein wrote: »

Steve,

I don't understand why the dhrystone program can't be build with SIDE. It looks like all that is needed is to copy dry.c to dry2.c and add "#define PASS2" to the beginning of dry2.c. dry.c and dry2.c should be included in the project file, and the following defines should be added to the compiler options:

-Dprintf=__simple_printf -DMSC_CLOCK -DINTEGER_ONLY -DFIXED_NUMBER_OF_PASSES=5000

The make file also includes the -O2 and -mfcache compiler options. It seems like it should work with SIDE.

Dave

Yes, tried that but no joy.

SimpleIDE compiles everything at once. That seems to be the big hangup. I'm looking into a possible option for compiling C files separately. Not being able to compile dhrystone with the IDE is "complicated."

pedward · 2012-06-06 15:40

Steve, why not have SimpeIDE manage Makefiles, then just shell out and run Make to compile?

jazzed · 2012-06-06 15:46

pedward wrote: »

Steve, why not have SimpeIDE manage Makefiles, then just shell out and run Make to compile?

The original target audience for SimpleIDE does not appreciate make - it's not "simple."
I may add an option for allowing user managed Makefiles in the future.

pedward · 2012-06-06 15:48

You are saying that SIDE does "gcc -o foo foo.c bar.c baz.c", and that doesn't work for Dhrystone?

jazzed · 2012-06-06 16:08

pedward wrote: »

You are saying that SIDE does "gcc -o foo foo.c bar.c baz.c", and that doesn't work for Dhrystone?

Yes, I get an odd problem that I don't quite understand yet. Here's my project if you want to have a look - in this case I add -DPASS2 globally for dry2.c to compile and undef it in dry.c.

pedward · 2012-06-06 16:14

Well, the first problem is that there is no times.h in the compiler distro. There seems to be several missing include files, were these in a later distro? I have the linux distro from a few weeks ago.

Looks like the include files for the newlibc are not included in the binary distro.

jazzed · 2012-06-06 16:22

Here is a dhrystone 1.1 that works in SimpleIDE for anyone who wants to use it.

It takes a little while for results to come out. Be patient. Here's what I get on an 80MHz Propeller board.

Dhrystone(1.1) time for 50000 passes = 7
This machine benchmarks at 7142 dhrystones/second

jazzed · 2012-06-06 16:25

pedward wrote: »

Well, the first problem is that there is no times.h in the compiler distro. There seems to be several missing include files, were these in a later distro? I have the linux distro from a few weeks ago.

Looks like the include files for the newlibc are not included in the binary distro.

Did you use the suggested -D flags?
sys/times.h is not required for freestanding standard C.

We do not use newlib for the C library - it's simply too big for Propeller.

Dave Hein · 2012-06-06 16:35

Steve, it looks like the #undef should work. What kind of error do you get? I wonder if there is a bug where #undef PASS2 affects PASS2 for subsequent files. Could you try a test where you don't use -DPASS2, and then define PASS2 in dry2.c?

jazzed · 2012-06-06 16:47

Dave Hein wrote: »

Steve, it looks like the #undef should work. What kind of error do you get? I wonder if there is a bug where #undef PASS2 affects PASS2 for subsequent files. Could you try a test where you don't use -DPASS2, and then define PASS2 in dry2.c?

Ya, tried that too. Same result.

Project Directory: /home/steve/gcc/propside/MyProjects/dry/


propeller-elf-gcc -o a.out -O2 -mlmm -I . -m32bit-doubles -fno-exceptions -Dprintf=__simple_printf -mfcache -DMSC_CLOCK -DINTEGER_ONLY -DFIXED_NUMBER_OF_PASSES=2000 dry2.c dry.c
dry.c:504:18: warning: conflicting types for built-in function 'malloc' [enabled by default]
dry.c: In function 'main':
dry.c:550:6: warning: incompatible implicit declaration of built-in function 'exit' [enabled by default]
dry.c:573:3: warning: incompatible implicit declaration of built-in function 'strcpy' [enabled by default]
dry.c:593:44: error: 'CLK_TCK' undeclared (first use in this function)
dry.c:593:44: note: each undeclared identifier is reported only once for each function it appears in
Done. Build Failed!


Click error messages above to debug.


Check source for bad function call or global variable name.

Ariba · 2012-06-07 12:27

I have modified the dry11 that jazzed postet in post #20, now it measures the time with the help of _CNT, and with a resolution of one-tenth of a second.
So I can reduce the loop count to 10000 - gives the result much quicker.

But the result are a bit questionable. Is a Propeller in LMM mode really 6 times faster than an Intel 286 with 7.5MHz? Or 200 times faster than a Commodore 64?
I wish this is true, and we really reach nearly the speed of an old Cray computer.

What is also a bit confusing: With this benchmark XMMC from SD card is faster than fom SPI-Flash. But both are still faster than the Intel286

It's also interesting to try different optimizations settings in SimpleIDE with this code.
If you set "O2 speed" or "O1 mixed" you get random results, seems the time measuring with _CNT not works then.

Andy

pedward · 2012-06-07 13:51

The 6Mhz 286 has only a 12MB/s memory bandwidth, not counting wait states.

I worked on an original IBM 6MHz 286 in High school and it had piggybacked 128Kb RAM chips to make 256Kb, factory supplied!

150ns was a common RAM speed in those days, 120ns was "fast", and 80ns was "holy cow!". Since 6Mhz is 167ns, it's possible that the 6Mhz 286 could access memory in zero WS mode.

The SD card specification says the minimum guaranteed clock speed is 20Mhz, which would be 20Mbits/s, which is 2.5MB/s. The Prop doesn't approach that speed, since it can only muster a 20Mhz clock, and AFAIK, attempts at serial comms top out between 14 and 20Mb/s when using the counter and highly optimized PASM. My recollection is that actual speed is a factor of 10 slower, around 250KB/s, at least with Kye's driver.

Where things get interesting is the instruction set. The propeller has a very competent RISC instruction set, with nearly all instructions taking 4 clocks. The 286 has a variable length instruction set, with instructions taking anywhere from 1 to 22 clocks IIRC.

Code density is another aspect that is used to compare microarchitectures. The DEC Alpha was an amazing chip when it was released, but it had very low code density, requiring a lot of memory access. Mhz for Mhz, it was very much slower than ia32 for mixed use. Where it shined was in SIMD calculations, which leveraged it's 64 bits instructions and 128/256bit memory bus. The Alpha uses a VLIW (Very Long Instruction Word) instruction set, which is very expressive, but highly inefficient except for very specific workloads. The ia64 microarchitecture also uses VLIW, and it's pretty much dead as well. The Transmeta Crusoe used VLIW, and is [again] dead.

The Prop is an interesting nexus of hardware and instruction set. The instruction set is small, but is very expressive, allowing you to do some very interesting things in very little clocks. For the most part it's straightforward, but there are a couple of interesting gems and peculiarities.

The Prop2 has extended the instruction set with some (a few) SIMD instructions. I would speculate that the next Prop microarchitecture would be 64 bit and feature a lot more hardware instructions for doing complex things, including additional SIMD instructions. I'd like to work with Chip on that project...

jazzed · 2012-06-07 13:54

Andy,

I'm not really sure how to respond to performance. Eric did the dhrystone2.2 makefile. The results are similar there to what I posted. Not sure who did the dry1.1 makefile. I just copied it to the SimpleIDE environment.

@peward's post does offer several insights.

The thing about the SDcard -vs- SPI flash is that large cache lines like used with SDcard increase small benchmark performance quite a bit. Real world apps are much better with smaller cache lines though.

Thanks.
--Steve

Ariba · 2012-06-07 15:37

Jazzed

This is the version you postet which can be compiled with SimpleIDE, so no makefile. The results are very different from the version which can only be compiled with the makefile.
At the begin of this c file you find some benchmark results from old computers, this is what I compare with the Prop in my previous post.

Andy

jazzed · 2012-06-07 16:26

Ariba wrote: »

Jazzed

This is the version you postet which can be compiled with SimpleIDE, so no makefile. The results are very different from the version which can only be compiled with the makefile.
At the begin of this c file you find some benchmark results from old computers, this is what I compare with the Prop in my previous post.

Andy

Hey you're right! I get 8333 drhystones/sec with the makefile version probably because it optimizes for speed. But even that is wrong.

The mystery gets deeper

In the original file time(0) should return number of seconds passed since the EPOCH if the time is right of course.

pedward · 2012-06-07 16:34

2 problems with the v1.1 dhrystone program. First, it doesn't account for CNT rollover. Second, it's not compiled with -O0 to disable the optimizer. The code is intentionally redundant and requires all of the statements to be meaningful. Additionally, the LOOP count should be higher, so the benchmark is more accurate. The code even suggests 500,000 if tolerable.

Lastly, the code doesn't take into account 8 COGs, so it really should be written to run LMM in 8 threads, then sum the results together.

ersmith · 2012-06-07 18:00

Ariba wrote: »

But the result are a bit questionable. Is a Propeller in LMM mode really 6 times faster than an Intel 286 with 7.5MHz? Or 200 times faster than a Commodore 64?
I wish this is true, and we really reach nearly the speed of an old Cray computer.

Actually the speeds are not too surprising. Just looking at clock speed, In raw PASM you'd expect an 80 MHz Propeller to be 10-12 times faster than a 7.5MHz 286. LMM adds about a 4x overhead, but GCC uses fast cache to hold small loops in COG memory so the speed on such loops approaches that of raw PASM. Moreover, the Prop is 32 bit, so some operations that require multiple instructions on a 286 will be done in just one instruction on the Propeller. So yes, the dhrystone results are reasonable (and moreover are accurate -- you can do the timing by hand to double check this).

Ariba · 2012-06-07 18:01

pedward

You are right, the optimizer seems to be the problem. The comments in the code say you need to switch offf the optimizer for modern compilers, because they eliminate a whole function if the result is not used.

I think I do handle the CNT rollovers, as long as the total time is under 27 seconds. With the counter the result is more accurate also with fewer loop counts, the original code can measure only in full seconds.

With no optimization I get reproducable results and the same results for the original and the CNT version (just faster):

LMM         2941
XMMC Flash  552
XMMC SDcard 609

Why not just multiply by 8 for LMM, if we need a high number for the Prop, it's anyway very theoretical. ;-)

Andy

Compiling dhrystone with simple IDE

Comments