Code Efficiency/Speed

[jecottrell]

3.236

I've got a multiconditional statement in my main loop:

[kender]

If I'm not mistaken, the ANSI C spec requires that:
- These operators guarantee left-to-right evaluation.
- If the compiler can make an evaluation by examining only the left operand, the right operand is not evaluated.

[Ttelmah]

What does ANSI have to do with it?.
CCS, is not ANSI C....
The difference wll be almost immesurable for simple simple 8bit values and tests, since adding an extra test/jump, will take as long as just anding in the extra byte...

Best wishes.

[jecottrell]

Kender,

Thanks for the info. I had wondered about the ANSI-ishness of CCS as noted in Ttelmah's response.

Ttelmah,

I think I understand your response, but I'm not positive. To further explain the situation, the 'if' statement is used in my main loop and obviously is tested every time through which adds overhead to the loop. Now, I have one particular case that will evaluate to FALSE 92% of the time. If I test that case first I will save any unnecessary branching... So, is there any way to maximize the efficiency of the multiple case 'if' statement?

I think in your previous reply you are saying that to test all the cases it is here nor there whether it is done either way. But my brain tells me that there must be some overhead in fetching and comparing extra conditions and if you can eliminate any unnecessary branches you'll save processing time? So, the sooner you can get out of the conditional branch the better?

[Mark]

The best way to know is to try them both and then look at the asm generated in the LST file.

[jecottrell]

Mark,

I had anticipated that response in my original post, that's why I asked the question about a good reference for PIC ASM. I found an OK online tutorial, but I always like to have a hard copy to dogear pages and markup. Do you know of any such animal?

BTW, I will try it and see if I can decipher the LST file.

Thanks,

John

[Ttelmah]

Ok.
The point about my answer, relates to how things work on the PIC. On many processors (most), there is a significant timing difference between the true, and false branches on a test. On the PIC, there isn't. The 'straight through' path, using a normal test, still fetches the extra instruction for the branch, and takes an extra cycle.
Now if you take three numbers, and need to logically combine them, and branch,the basic sequence would be:
load number 'A' into W.
combine with 'B'.
combine with 'C'
test and branch.

This can actually be done in five machine cycles (plus any overhead for bank switching).

If instead you 'double test', you get:
load number 'A' into W.
combine with 'B'.
test and branch.
combine with 'C'
test and branch.

The 'best' case, drops to 4 machine cycles, but for everyting that needs the second test, the time now rises to 7 cycles.
For your 90% probability, it would then be worthwhile to do the shorter test, but in many case it wouldn't (anything with less than 66% probability for the first test, it is not worthwile).
However this makes a 'key' assumption in both cases, that the registers being tested, are in the same bank as is being used by the operational registers in the rest of the particular routine. If they are not, another four machine cycles need to be added (potentially for each switch). The problem here, is that because the registers need to be restored before the branch, or seperately afterwards, this more than doubles the cycles involved. Also, the 'combine' operation, is assumed to be a single machine operation. This is not the case for more complex logic, which can result in the 'all in one' operation taking the lead.
Whether shortcutting gains anything, depends particularly then on the logic operation involved. In fact in your case, the logic evaluates as:

if ((a!=0) && (b!=0) && (c!=0))

On the PIC, loading a value from a register, sets the 'Z' flag if the value is zero, so the compiler takes advantage of this, and does not combine the values at all, but instead simply reads each one in turn, and jumps past the code to be called if this value is non zero. Also on the latter 18 chips, there is a single instruction 'short' jump for the zero condition, and this can be used to make this really efficient, provided the code inside the test is short. This is by default done, and identical code will be generated for the combined, or the separate operation.
However it also becomes vital to use the .sym file, and verify that all registers used in the core 'fast' loop, reside in the same bank (change the order they are declared if not), and even better, make sure they are in the first bank (where scratch variables etc., are stored), since otherwise it is the bank switching which will cost the most in time. Also keep the total length of the code inside the routine called if the test is true short (if there is a subroutine, make sure it is not coded as 'inline'), or the longer (slower) jump will need t be used.
PCM programmer has published notes in the pst about how to optimise register layouts, and while these my seem not to apply to the 18 chips (where there are single instructions to fetch values from any part of the memory), they are still just as important, since these larger instructions, take two machine cycles...

Best Wishes

[jecottrell]

Thank you very much for the in-depth explanation. I saw some of what you explained as a picked through the LST and SYM files. I even saw that one of my conditions was a function with a return value and the increased overhead that it cost.

I also saw the 'straight through' concept you explained. Now it seems rather obvious. On a processor of limited size, when testing a variety of conditions, A && !B && C, etc., that each will be done individually then branch. I DID NOT realize that similar conditions would be combined prior to testing. That is interesting, but makes complete sense.

What I've really learned is, is that I probably don't need to worry about this yet. But it is very interesting to start to understand the underlying ASM generated from the C code.

Thanks again,

John

[Humberto]

Nice and interesting discussion. Let�s say that the CCS compiler handle very efficiently
all regarding bit/test and the generated code is as short and efficient like in ASM.


It doesn�t matter the coding style you use, it�ll give you the SAME generated code:

[jecottrell]

Humberto,

Thanks for the test. What part is that targeted for? I noticed in my experimentation for the 18F2525, that it uses a BRA (branch?) instruction where yours uses a GOTO. I'm wondering if the behavior that Ttelmah describes, combine and then branch is unique to 18F parts?

Even then, I still have decided that there is a slight gain to be realized depending on the test values. My example in my first post should have been more accurate and have looked more like this:

[Humberto]