Calculating Processor Overhead - 20x2 @ 64mhz

20x2 @ 64mhz Processor Overhead


My purpose here was to determine with fairly good accuracy, the processing overhead time of various BASIC commands using a Picaxe 20x2 operating at its maximum speed of 64 Mhz.

Method:

The the period of the test loop was measured with no test command added. At 64MHz, this was 148us using a value of 100 for pulsout. I then put the command to test within the loop and measured the period again. The difference is the time it takes to execute the command and should be a good indicator of processor overhead for these commands.
Measurements were taken with with a TektronixTHS730A Digital Oscilloscope using the Period Measurement feature.

The test code is as follows:

Here are the results for various BASIC commands. All measurements are in microseconds

Base Period = 148us

Command ........... Period ..... Time us

readadc10 .......... 219.4 ...... 71.4
readadc ............ 219.2 ...... 71.4
pause 0 ............ 172.8 ...... 24.8
pauseus 0 .......... 172.8 ...... 24.8
pulsout c.0 ,0 ..... 188.6 ...... 40.6
let b0 = 1 ..........181.4 ...... 33.4
inc b0 ............. 192.8 ...... 44.8
b0 = b0 + 1 ........ 192.8 ...... 44.8
w0 = w0 / 2 ........ 258.0 ...... 110.0
w0 = w0 / 22 ....... 248.0 ...... 100.0
w0 = w0 / 222 ...... 235.2 ...... 87.2
get 0,b1 ........... 188.6 ...... 40.6
get 0,b1,b2 ........ 228.8 ...... 80.8
read 0, b1 ......... 188.8 ...... 40.8
read 0, b1,b2 ...... 228.8 ...... 80.8

What's the hsersetup thing for?

Goeytex said:

w0 = w0 / 2 ........ 258.0 ...... 110.0
w0 = w0 / 22 ....... 248.0 ...... 100.0
w0 = w0 / 222 ...... 235.2 ...... 87.2

Click to expand...

Amazing - dividing by bigger numbers is actually quicker. Did you try using >> 1 instead of / 2 as well?

That seems to be in the expected ballpark and my 'rule of thumb' of 32us for simple commands such as HIGH and LOW. But have a read of past forum discussions particularly with respect to token sizes and alignment in memory of commands and parameters which will affect timing and also affects the timing of subsequent commands, so the loop time you subtract is never going to be consistent.

It's a bit like quantum physics where testing the timing affects the timing so there cannot be absolute accurate results determined this way.

The hsersetup is there because I also measured and compared serout vs hserout commands. But I did not include those results here. And as I stated, I was only after "fairly good accuracy" not absolute accuracy.

The results here should be good enough to give users a fair idea of what to expect.

Some of the information that hippy has made reference to wrt tokens, optimisation, etc, is to be found here: http://www.picaxeforum.co.uk/showthread.php?17782-PICAXE-program-Size-Optimisations-and-Speed
it is a compilation of data by hippy, beaniebots and myself.


EDIT:
Comparing the data by Goeytex with some actual plus extrapolated data from my own past instruction timing checks, the approx command timings are still in the same order. Determination of instruction duration by halving the duration when doubling the speed still appears to serve as a reasonable approximation though the 20X2 does consistently have instruction durations about 10% greater than would be forecast by the “double and halve” rule compared to the 28X2 data to hand.

As hippy has mentioned, all timing is approximation due to the method of program compaction to save save and therefore variable duration to extract a command for interpretation.