If you want to know what the compiler does, you can look at the disassembly (look at the DP8051\DP8051_Keil_903\Debug\ folder in your project). But you need to do the cycle counting by yourself - together with a 8051 assembler reference and the knowledge how the stuff is executed in the end (e.g. pipelining).
Given that the PSoC3 should be faster than the PSoC1, you should have no performance problem - or do you need even higher speed?
When you really care about execution performance: can your problem maybe solved by moving it into hardware? The UDBs with their datapath, and also the digital filter block are rather mighty components...
Performance measuring is not only related to the number of clock cycles needed. The different processor architectures already have a big influence on performance. I tested the same C-code on a PSoC1 and a PSoC5 and found a speed improvement of factor 25 for this special application.
Comparing clock cycles of instruction/operation between two different type of CPU is meaningless. I think the better comparision would be how fast the same task completed by the processors.
There are many pertainent methods of measuring speed and thruput,
and clock cycles is certainly one of them, especially when one is working
at the HW level. Crtical HW control loops just to name a few.
Example, implementing a fast integer FIR, first thing I would look at
is multiplying and sum speed, in clock cycles, to get an idea of sample
rate I can achieve, as in FFT, FIR, IIR, correlation, auto correlation.....
Clock cycles also give us an idea of how much serialization, eg. save
gates, vs parallel, balls to the wall is in the architecture.
The point Bob made, looking at an overall task thruput, via timing, certainly
makes sense for many investigations, if a process takes a minute on a 48 MIPs
machine it would be foolish to try to measure it via clock cycles.
There is a place for clock cycle discussions. All food groups are welcome.
Checking clock cycle to check the performance of a chip is useful when checking the performance of different instructions or different implementaion of a function ON the SAME CHIP or chips with SIMLIAR architecture.
BUT comparing clock cycles with PSoC1 and that PSoC3 which are of different architecture is of little use.
How fast a function can be completed byt the two chips with the same function would be more meaningfull.
Clocks x Clock Period = HW time which one uses to evaluate HW component speed, like a multiplier
Time to run a f() = Software time generally is HW time + overhead and fluff.
If f() time is not adequate I start to look at Clocks to see what is achievable before I
throw away the part from consideration. FLOPS in a part are not f() related, but
critical in DSP operations.
I use both to evaluate processors and architectures.
number of clocks * clock period is time.
I think we both agree that's how it should be measure. (Of course the overhead is needed to take into consideration, again this is time ).
I still in the old days, we try to find instructions such as
LDA 0; ie load accumlator A with 0
and change to
CLRA; clear acculator A
to save 1 byte and a few cycles of instructions.
thanks for your answers have been helpful, is that the performance of a 8051 can not be cmparado with the M8C, but since this is my grade, is one of the things I have asked this same measure as proyectoe s implemented in 8051 and reported a microcontroller clock cycles.
In that case, look at the disassembly (as stated before). The PSoC3 TRM lists, starting on page 40, the number of cycles needed for each assembler instruction. Note that the PSoC3 executes the instructions in 1 or 2 clock cylces, as opposed to 12 of the original 8051 (OK, some instructions need up to 6 cycles...).