Jump to content

Search the Community

Showing results for tags 'optimization'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • PIC Embedded Programming
    • BoostC and Chameleon compilers programming
    • BoostC porting source code
    • BoostC++ compiler programming
    • BoostBasic compiler programming
    • Assembler programming PIC
    • Novo RTOS Programming
    • Hardware PIC
    • Enhancement Requests
    • Bug Reports

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 3 results

  1. Dear all, Two questions about how to optimize a for loop when compiling with the BoostC compiler. 1) Let's say I want to iterate over a value 'x' from 0 to a limit. I've been taught it's the best way to calculate the max. limit before entering the loop when using the C++ Borland compiler. Then the compiler won't need to execute the right operand of the conditional expression (calling a function xvalue() + adding one) hence improving execution time. // The best way when using a Borland C++ compiler like I've been taught unsigned int limit = xvalue() + 1; // where '+1' is the calculation and xvalue() some function returning a limit which is the same every iteration for (i = 0; i < limit ; i++) // limit is a fixed number // do something // A less good way using a Borland C++ compiler unsigned int limit = xvalue() + 1; // where '+1' is the calculation for (i = 0; i < xvalue() + 1; i++) // the function xvalue will be called as well as the addition will be performed every iteration // do something By calculating the limit before you enter the loop you save (one function call + one addition) times the number of iterations. What kind (if any) optimizations does the BoostC compiler perform? Maybe the compiler is able to optimize this structure any way (like most modern compilers - I am talking from a non embedded compiler side now-. 2) Last year I had a project with a dual-core Blackfin DSP processor (from Analog Devices). We discovered that it was way faster to replace the 'less than or equal to' sign in the the conditional expression by a 'less than' sign some_limit + 1. // slow code for (i = 0; i <= LIMIT; i++) // do something // faster execution time for (i = 0; i < LIMIT +1; i++) // do something Does the same logic goes up for the BoostC compiler? Thanks in advance, All the very best, Andy
  2. How can I implement a very efficient "jump table" using BoostC? I am trying to implement a jump table equivalent to this (the code needs to be fast): pcl += value; goto label1; goto label2; goto label3; etc. I've run into several issues: 1. First I tried function pointers, but they generate bulky code so now I am just trying to add an offset to pcl which will skip to a goto 2. The compiler is removing what it thinks is "dead code" (after the first goto), even with optimization turned off ("-O0") 3. After it removes the "dead code" gotos, it sees unreachable code (the target code fragments) so it removes those also. I have tried this with BoostC 7.10, 7.051 and 7.04, with the same results. Target device is PIC16F1827, '1823, or '688, but I don't think that matters. O/S: Windows XP, but I don't think that matters. Below is my sample code: -------- //BoostC dead code removal can't be turned off //this happens with 7.10, 7.051 and 7.04 also (not tested prior to that) #include <system.h> //do not use this line for libraries typedef unsigned char uint8; #pragma OPTIMIZE "0" //this doesn't avoid "dead code" removal void main(void) { uint8 var1, var2; var1 = 1+2; //example; calculate jumptable offset here pcl += var1; //pclath is assumed to already be set correctly //the following statements are being removed even with optimization turned off: goto here1; goto here2; goto here3; goto here4; //below are example code fragments: here1: porta = 1; return; //the following are being removed unless a conditional "goto" to them is added elsewhere: here2: porta = 2; return; here3: porta = 3; return; here4: porta = 4; return; } -------- I can defeat the dead code removal by using code such as the following: if (never_zero == 0) goto here1; if (never_zero == 0) goto here2; if (never_zero == 0) goto here3; if (never_zero == 0) goto here4; but this is bulky because it takes 2 instructions for each jumptable entry, and it also needs a left-shift of the jumptable offset variable before it is added to pcl (which is even more overhead). This topic is related to an old post which implied that asm statements would help: http://forum.sourceb...p?showtopic=680 I tried using an asm block: asm { goto here1; goto here2; goto here3; goto here4; } and this preserves the jumptable itself, but the target code fragments are still being removed and then the linker complains that it cannot find the labels - linker error is: Internal Error: Unable to resolve label ID:268435717 - 0x10000105 Turning off linker optimization ("-O0") avoids this error, but that is a global switch and I do not wish to turn off optimization for the entire module. Any other suggestions of how to solve this? thanks don
  3. Bug description: Optimization is leaving extra instructions in the example cases below. Steps to reproduce: Example 1: unsigned char var1, var2; var1 = var2 = 0; code generated: clrf var1 movlw 0 ;this instr is not needed clrf var2 Example 2: unsigned char var3, var4, var5; var3 = 3; var4 = var3; var5 = var3 + var4; code generated: movlw 3 movwf var3 movf var3, w ;this instr is not needed movwf var4 movf var4, w ;this instr is not needed addwf var3, w movwf var5 Expected behaviour: Example 1: clrf var1 clrf var2 Example 2: movlw 3 movwf var3 movwf var4 addwf var3, w movwf var5 Is the problem 100% reproduceable: yes Compiler: BoostC Compiler version: 7.10, 7.051 and 7.04 also (I didn't test prior to that) Target device: PIC16F1827, '1823, '688, etc. OS: Windows XP don
×
×
  • Create New...