Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

if statement alternate needed.

Status
Not open for further replies.
sagar474

sagar474

Full Member level 5
Joined
Oct 18, 2009
Messages
285
Helped
5
Reputation
10
Reaction score
5
Trophy points
1,318
Location
India,kakinada
Activity points
3,122
if((c>=65 && c<=90)||(c>=97 && c<=122)||(c>=48 && c<=57))
I'm following if statement in my code
I think it takes more execution. is there any alternative. to do this?
 

What makes you think it takes more execution ?
it depends on the compiler and if compiler is smart enough, how you code it doesn't make much difference.
 

You might be able to save a few clock cycles by doing this:
Code: 
if( c>=65 && c<=90 )
    FUNCTION_IF_TRUE();
else if ( c>=97 && c<=122 )
    FUNCTION_IF_TRUE();
else if ( c>=48 && c<=57 )
    FUNCTION_IF_TRUE();

The first if statement takes 6 steps (4 to evaluate the if, then 2 to evaluate the else's), the second takes 9 steps (1st if + 2nd if + else), and the third takes 12 steps (1st if + 2nd if + 3rd if). Your original if statement takes a minimum of 12 steps to evaluate.

If you know that one range will occur more often than another two, put that range into the first IF statement so that it triggers first... then your code will only have to execute 6 steps to jump into the common code (inside the IF_TRUE function), compared to the minimum 12 of the original method.
 
Thank you enjunear it saves few clock cycles but the statement should be executed thousands of times in my code hence It saved thousands of clock cycles, it is very effective solution.
 

Actually, it is hard to tell if using if-else can save some clock cycles... If - else will be translated to multiple branch instructions and it creates more chance of misprediction and CPU may have to backtrack.. This is a typical case of performance loss in today's processors that employs speculative execution. Branch instructions are evil for computer architecture that disrupts the pipeline and in general, it's better to have fewer branch instructions.
Unless you know how gcc works, or there is a very obvious reason to believe a certain code can get a better performance, i don't think it's worth to play with coding style too much.
 

lostinxlation said:
Actually, it is hard to tell if using if-else can save some clock cycles... If - else will be translated to multiple branch instructions and it creates more chance of misprediction and CPU may have to backtrack.. This is a typical case of performance loss in today's processors that employs speculative execution. Branch instructions are evil for computer architecture that disrupts the pipeline and in general, it's better to have fewer branch instructions.
Unless you know how gcc works, or there is a very obvious reason to believe a certain code can get a better performance, i don't think it's worth to play with coding style too much.
Click to expand...
yes you are right branching instructions effects the pipelining of the processor but there is no way to completely avid the if statement.
 

I think switch statement is better to use it saves number of clock cycles and makes execution faster......what do you all say??
 

sagar474 said:
if((c>=65 && c<=90)||(c>=97 && c<=122)||(c>=48 && c<=57))
I'm following if statement in my code
I think it takes more execution. is there any alternative. to do this?
Click to expand...

Yes. The condition of the if statement is evaluated from left to right, evaluation ends upon the first false condition in each of the logical && subconditions and then begins evaluation of the next subcondition in the same.

Therefore the ordering of each of the contents of these subconditions, (c>=65 && c<=90), (c>=97 && c<=122), (c>=48 && c<=57), can determine execution time.

By ordering the contents of each of these subconditions so that the least likely is evaluated first, the next least likely evaluated second and so forth, execution time can be shortened.

As far as employing different conditional and branch structures, the resulting machine code can be largely compiler and optimization dependent and would require analysis and timing of the compiled code of each of the alternatives.

BigDog
 
Last edited:
yanamaddinaveen said:
I think switch statement is better to use it saves number of clock cycles and makes execution faster......what do you all say??
Click to expand...

I agree, but the disadvantage of the switch statement is that it can be used only when compare with absolute values is involved and not compare with range of values like this thread's example.
 
bigdogguru has mentioned the points, that result from C expression evaluation rules. Following this rules, there's no clear indication for execution time difference between the code variants from post #1 and #4. Differences may however happen according to the implementation details of a particular compiler.

A switch statement isn't a good option in this case, because C don't know case expressions with ranges (as e.g. Pascal or VHDL have). But apart from this restriction, the assembly level implementation of a switch construct usually doesn't look much different from an if..else if..else chain.

Depending on the used tool, much of the execution time can be however caused by compiler laziness, e.g. loading the variable c multiple times from memory. This happens particularly with some embedded compilers.

Considering a bad optimizing compiler, an optimal assembly language implementation can save at least a few cycles. The ultimate speed-up means for lengthy switch constructs is however a jump or decoding table. It's extensively used by high optimizing compilers, e.g. MSVC. Good embedded tools also have it as a maximum speed trade-off variant.
 
if((c>=65 && c<=122)||(c>=48 && c<=57))
{
var[a]=c;

}

Code: 
0x80487e8	cmp    bx,0x40
0x80487ec	jle    0x80487f4 <main+128>
0x80487ee	cmp    bx,0x7a
0x80487f2	jle    0x8048800 <main+140>
0x80487f4	cmp    bx,0x2f
0x80487f8	jle    0x804881e <main+170>
0x80487fa	cmp    bx,0x39
0x80487fe	jg     0x804881e <main+170>
0x8048800	movsx  eax,si
0x8048803	add    eax,DWORD PTR [esp+0x1c]
0x8048807	mov    edx,ebx
0x8048809	mov    BYTE PTR [eax],dl
0x804880b	add    esi,0x1
0x804880e	mov    eax,DWORD PTR [esp+0x18]
0x8048812	mov    DWORD PTR [esp],eax

if((c>=65 && c<=122))
{
var[a]=c;

}
else if(c>=48 && c<=57)
{
var[a]=c;

}
else break;
Code: 
0x80487ec	jle    0x8048801 <main+141>
0x80487ee	cmp    bx,0x7a
0x80487f2	jg     0x8048801 <main+141>
0x80487f4	movsx  eax,si
0x80487f7	add    eax,DWORD PTR [esp+0x1c]
0x80487fb	mov    edx,ebx
0x80487fd	mov    BYTE PTR [eax],dl
0x80487ff	jmp    0x8048818 <main+164>
0x8048801	cmp    bx,0x2f
0x8048805	jle    0x804882b <main+183>
0x8048807	cmp    bx,0x39
0x804880b	jg     0x804882b <main+183>
0x804880d	movsx  eax,si
0x8048810	add    eax,DWORD PTR [esp+0x1c]
0x8048814	mov    edx,ebx
0x8048816	mov    BYTE PTR [eax],dl
0x8048818	add    esi,0x1
 
Last edited:

As expected, excecution time is basically identical between both variants, taking the same number of compares and jumps in both cases. Because it's a "dumb" embedded compiler, that reads code literally line by line, the second variant doubles the variable assignment, needing more code space.

By the way, what's the compiler, does it offer any variable optimization settings?

EDIT: The comment isn't valid for the above assembly code, which has changed in the meantime.
 
Last edited:
yes you are right it takes more space in second case.
but what i have noticed is if c<=122 there is no need to compare if(c>=48 && c<=57) but in second case it is doing that. there is same type of problem in case one.
is there is any way to avoid this?

---------- Post added at 21:41 ---------- Previous post was at 21:33 ----------
FvM said:
Because it's a "dumb" embedded compiler
Click to expand...
what is "dumb" embedded compiler ?
 

What did you change to post #12, I'm under the impression, that it isn't the code I've seen previously. There's apparently something missing.

what is "dumb" embedded compiler ?
Click to expand...
A compiler that e.g. isn't able to detect repetitions in the code. As said, it may be a matter of low optimizations settings as well.
 
FvM said:
What did you change to post #12, I'm under the impression, that it isn't the code I've seen previously. There's apparently something missing.
Click to expand...
yes i have removed some check to optimize. although the concept of question is not changed.

FvM said:
A compiler that e.g. isn't able to detect repetitions in the code. As said, it may be a matter of low optimizations settings as well.
Click to expand...

I enabled the code profiler. will it effects the compilation?
 

As FvM asked in a previous posting, what compiler are you using?

Is the target an x86?

BigDog
 
sagar474 said:
but what i have noticed is if c<=122 there is no need to compare if(c>=48 && c<=57) but in second case it is doing that.
Click to expand...
You snipped the code and I can't see that.

there is same type of problem in case one.
Click to expand...
are you certain ?
I'm more familiar with SPARC, not x86, but it looks to me the code behaves exactly like you expect from C that follows the priority rule.
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top