views:

745

answers:

5

I try to measure the clock cyles needed to execute a piece of code on the TMS32064x+ DSP that comes with the OMAP ZOOM 3430 MDK. I look at the "Programmer's Guide" of the DSP chip and it says that the DSP supports the clock() function.

What I do is really simple, I just do

start = clock();
for (i=0;i<100;i++){
    /* do something here */
}
stop = clock();
total = stop - start;

and then put the values of "start","stop" and "total" to a previously allocated shared memory with the ARM processor. Then I simply print it to the screen at the ARM side.

The problem is, in my first executes, I always get the same "total" value, and then in my next runs I always get 0! The "start" and "stop" values go along with the "total" value.

The strangest thing is that they seem to follow a bit pattern! I put the output below:

# ./sampleapp
Total = 63744
Start clock() value = 0x000000f9
Stop  clock() value = 0x0000f9f9
# ./sampleapp 
Total = 4177526784
Start clock() value = 0x00f9f9f9
Stop  clock() value = 0xf9f9f9f9
# ./sampleapp
Total clock cyles = 0
Start clock() value = 0xf9f9f9f9
Stop  clock() value = 0xf9f9f9f9

Apparantly, clock() is not functioning well, but I'm not sure if this is because of something I do wrong or because this type of thing is not supported with the hardware I have. Any ideas why this might be happening?

A: 
AIB
Yes, you're missing the fact that the code shown runs on one processor, the DSP, while the code that displays the results runs on another, the main ARM CPU.
unwind
A: 

Maybe you need to initialize the clock first.

swegi
As far as I know clock() takes the reference point as the initial call of the executable. I don't know how to initialize/reset its value manually. How do you do that?
Can Bal
I've just reread the man pages, the standard gives no way to do such a thing.
swegi
A: 

How are you printing it out? maybe the issue is actually with displaying the result?

on most platforms clock_t is a long long. If you're using printf with %d you might get variable results which is what you're seeing.

Matt H
I printed out sizeof(clock_t) and it is 4. It is defined as unsigned int.
Can Bal
To persist on this vein, is your printing code proven good? Have you fed some values through the same kind of memory transfer / printout to check if they come accross correctly?
DevSolar
A: 

Assuming the start and end variable are of type 'clock_t', and your shared memory assumes the same on the other end's interpretation of the numbers passed, then your problem is not with the call to clock, and your handleing of the difference between the start end end times.

I believe your problem is in the shared memory between the two. Can you please post code to show how you're sharing memory between two separate processors?

Kieveli
I simply use the same method TI used through its dmmcopy sample.MPU side sample:http://gitorious.org/ti-dspbridge/userspace/blobs/master/source/samples/mpu/src/dmmcopy/dmmcopy.cDSP sample:http://gitorious.org/ti-dspbridge/userspace/trees/master/source/samples/dspBut I don't think the problem is with the shared memory since I can pass hard-coded values from DSP to CPU correctly instead of the start stop and total variables.
Can Bal
+1  A: 

From reading the questions so far, I'd say the Original Poster has substantially more knowledge of this matter than the contributors so far, and that the suspicion that the clock() is broken (or not supported, and returns an undefined result) on the DSP seems quite likely.

Will
I started to believe that this is the case too, so there is no need to leave this question as unanswered anymore. Thanks to you all.
Can Bal
How humble of you Can Bal, that you have started to agree to believe that you have substantially more knowledge than the contributors, and selected as the answer the one stating that one. nice :) I agree that clock() is broken too, however, on OMAP.
ustun
It seems you are not the only person having trouble with clock(). Perhaps the solutions provided here will be of help. http://stackoverflow.com/questions/588307/c-obtaining-milliseconds-time-on-linux-clock-doesnt-seem-to-work-properly
Matt H