Is time.h clock () broken on my hardware?

Question

I am trying to measure the clock cycles needed to execute a piece of code on the TMS32064x + DSP that comes with the OMAP ZOOM 3430 MDK. I look at the "Programmers Guide" of the DSP chip, and it says that the DSP supports the clock () function.

What I'm doing is really simple, I'm just doing

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

and then put the values ​​"start", "stop" and "total" in the previously allocated shared memory with an ARM processor. Then I just print it on the screen from the ARM side.

The problem is that in my first performance I always get the same “common” value, and then in my next runs I always get 0! The start and stop values ​​are the same as the full value.

The strangest thing is that they seem to follow a little 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 

Clock () is obviously not working correctly, but I'm not sure if it is because I am doing it wrong or because this type of thing is not supported by the hardware that I have. Any ideas why this might happen?

Answer 1

After reporting the questions so far, I would say that the Original Poster has much more knowledge about this than until now, and that the suspicion that clock () is broken (or not supported) and returns undefined) on the DSP seems quite likely.

Answer 2

Curious why you need previously allocated shared memory . Why don't you try the regular stack variable? Is there something I am missing?

Answer 3

You might need to initialize the clock first.

Answer 4

How do you print it? maybe the problem is displaying the result?

on most platforms, clock_t is long. If you use printf with% d, you can get the variable results that you see.

Answer 5

Assuming the start and end variables are of type 'clock_t', and your shared memory assumes the same thing with a different interpretation of the numbers passed, then your problem is not related to the call to the clock, but your handling of the difference between the start end times.

I believe that your problem is the shared memory between them. Can you send code to show how you use memory between two separate processors?

Answer 6

Perhaps you can use some built-in assembly to directly access the CPU counter registers.

The TMS320C64x + has a 64-bit timestamp register in TSCL, TSCH. The counter is not turned on to reset, you must first write to the register to start the counter (maybe this is a problem with clock ?). Reading from the register is not entirely trivial, since each half must be read by a separate instruction (and you can get interrupts ...).