My first post here, firstly let me thank the MikroElektronika team for producing a great product, especially for making it easy for people with Visual Basic experience, the transition to MikroBasic has been painless, and I also appreciate the Visual Studio like IDE. I was programming PICs in ASM about 8 years back on a hobby project and found it fairly hard for a beginner specifically for the learning curve but did manage to get some fairly complex coding done. Now I'm coming back to the PIC for another project and my productivity is considerably faster with the MikroElektronika tools. I also appreciate that the compiler/IDE is free for code under 2K which makes it painless to use MikroElektronika for hobby work, as you can do a hell of a lot in 2K, especially if you optimise your code (the topic of this post!).
My question is around how to optimise my code for ROM size. I made a bulk purchase of 16F628 chips with the 2K ROM limit for a hobby project (home automation) which I thought would be sufficient for my needs but like all good projects the functionality scope has blown out
, and I am running short of code space. I have noticed comparing my old ASM code to the ASM output of MikroBasic that there is an efficiency difference, but its not huge and its to be expected. It looks like out of the 2K of ROM by the time I finish debugging I will end up about 100 instructions too many, and I expect I should be able to make the final code fit with hand optimisation. However I have spent a couple of hours searching this forum looking for optimisation tips and surprised that there is not more discussions or even a FAQ / sticky on the best tips for optimisation - possibly because the standard answer is buy a larger PIC, which is not always the right answer. Most posts are about optimising a particular code snippet, I could not locate a post with a collection of more general tips (hence I thought I'd start this topic).
Another consideration is that a smaller code base most of the time equals faster running code, so the benefits are not just using less ROM, although you may end up with code less obvious/readable as a downside (for maintenance). It was also surprising that a few of the techniques I had found with experimentation with the compiler have not been posted, so I thought I would share my findings, collect other tips from this community as well as ask for optimisation help with a few of my routines that I am stuck on optimising.
I see member 'xor' has been active with helping people with optimising, so I'm hoping he will chime in, or at least provide links to similar topics that I may have missed in my seach (although I have spent a couple of hours searching / reading!). Some of the below tips are obvious (to experienced folks) but still useful reminders.
So for my tips:
1) Less lines of Basic does not always mean tighter ASM code. I have noted that when I combine functions on a single line that about 50% of the time the compiler uses less instructions if the expression is decomposed into separate lines. I have noted a couple of examples below, but as a general rule I will try a more complex expression split over several simpler lines and check to see the ROM difference with a build (usually quick to try).
2) Use simple types. As soon as you start using more complex types (eg. words), the compiler has to split your variable into different registers and shuffle the registers around etc.
3) Always do integer arithmetic. Any floating point or more complex mathematic expressions will always blow the code out. You may need to make approximations in your code and live with a margin of error, but if accuracy is not important you will have smaller (and faster) code. Use addition / subtraction over multiplication / division if possible.
4) If you can multiply or divide by a power of 2 (eg. divide by 2), you can save a bit of code by using the >> or << operator instead of using division. Sometimes the compiler will optimise for shifts but I have seen a couple of scenarios where it didn't.
5) Do not put multiple condition tests in the same IF statement. I'm not sure why the compiler does not optimise this well, but a statement like:
IF (Rx_Buffer[Data0] = DataSize) AND (RxPtr <> 0) THEN ....
can have the AND condition split into 2 lines, which is more lines of Basic but less ASM code, like:
IF Rx_Buffer[Data0] = DataSize THEN
IF RxPtr <> 0 THEN .....
For OR conditions, use a local boolean variable before the IF/THEN test and assign your boolean to the logic test, then test the boolean in the IF/THEN (although I have not been able to save any space doing this). The next version of the compiler with SSA optimisations will be smarter about optimising more complex IF/THEN constructs.
6) It does help learning ASM and writing ASM as you will get a better appreciation of how the 'machine' runs. If you can keep your Basic code to as close an approximation to how it would work in ASM the code is always tighter. All the high level programming constructs come at a cost, more code & slower, as the compiler has to decompose your code down to ASM anyway.
7) A good example of the above is use of boolean operators. You can do some pretty fancy integer operations/tests with boolean logic although sometimes it takes a bit of thinking/experimentation to get it right (which I would never bother with in Visual Basic as it just didn't matter). An example is using XOR to test for a change in bits (eg. a port), you can save many instructions compared to using a higher language construct like looping through a variable's bits like 'variableX.Loop'.
8 ) Replace your Basic code with more optimised inline ASM. This needs a bit of extra work and the code is harder to read but it is a good way to optimise code. Usually you will need to read the compiler ASM output listing and work out a more efficient way in ASM, and replace the Basic code with inline ASM. Example below.
9) When doing multiple shifts << or >>, or power of 2 division/multiplication, you can optimise the ASM by removing the clearing of the carry bit each time a shift happens. The compiler can't tell what you are doing, so plays safe by assuming you don't want the carry (which most times you don't). You can AND out the redundant carry bits at the end. For example when processing nibbles:
Variable >> 4
compiles to:
MOVF FARG_LCDWriteByte_LCDByte+0, 0
MOVWF FARG_SetOutputs_OutVal+0
RRF FARG_SetOutputs_OutVal+0, 1
BCF FARG_SetOutputs_OutVal+0, 7
RRF FARG_SetOutputs_OutVal+0, 1
BCF FARG_SetOutputs_OutVal+0, 7
RRF FARG_SetOutputs_OutVal+0, 1
BCF FARG_SetOutputs_OutVal+0, 7
RRF FARG_SetOutputs_OutVal+0, 1
BCF FARG_SetOutputs_OutVal+0, 7
But could be replaced with:
MOVF FARG_LCDWriteByte_LCDByte+0, 0
MOVWF FARG_SetOutputs_OutVal+0
RRF FARG_SetOutputs_OutVal+0, 1
RRF FARG_SetOutputs_OutVal+0, 1
RRF FARG_SetOutputs_OutVal+0, 1
RRF FARG_SetOutputs_OutVal+0, 1
MOVLW 15 ' %00001111
ANDWF FARG_SetOutputs_OutVal+0, 1
(in this case use of the ASM SWAPF command would be even better)
10) Use of local variable scope over globals. I use a lot of state machines in my code, and globals are perfect especially as you usually want to keep your ISR processing to a minimum and save the heavy processing for the main loop. However I have found that over use of globals adds bloat sometimes to the code because the compiler has to perform bank switching when accessing PIC RAM in different locations. Using local variables also has the opportunity to reduce RAM use if the compiler can use an available register rather than RAM.
11) To reduce the amount of bank switching the compiler must do when accessing globals, try to group the globals that will be used together into the same memory bank by forcing the compiler to place these variables in the same RAM locations using the 'absolute' statement when declaring the variable. You will need to study your PIC datasheet to work out the relevant memory banks (eg. PIC 16F628 has 4 memory banks that are quite fragmented and shared with the registers). You can also hand optimise the code by replacing Basic with ASM and removing the unnecessary bank switching (be careful - the compiler assumes the banks are not changed to you have to restore the bank settings at the end of your ASM, else you can introduce nasty bugs). Its preferrable to keep the most commonly used variables in Bank0. Credit help for this tip - Janni.
12) Always view the ASM listing after adding/changing new code looking for large chunks of ASM code for small lines of Basic. Also always look at the changes in the number of instructions used in the ROM at the end of the compiler output when compiling. Be curious and try a couple of different ways of doing the same thing, I have found a number of times that a small change to the Basic expression can make a difference to the code used, and a lot of times the change was not obvious.
13) The MikroElectronika libraries are generally not code efficient. I have pretty much found I can beat them in efficiency if I write equivalent functions as I have the luxury of coding to my specific requirements, not for the general case as the libraries have to be (and note that this is not a fault of MikroElectronika, their libraries have to be written to the general case for multi-use). For example, replacing the UART init routine with equivalent Basic statements below saved a bit of space and was easy to do:
SPBRG = 129 ' 9600
TXSTA = %00100100 ' Async, 8 bit, enable Tx, High baud rate, clear transmit shift register, clear 9th bit
RCSTA = %10010000 ' 144 Enable serial port, enable continuous receive
14) Use of symbols. Not only do they increase the readability of the code, replacing a numeric constant with something more readable/maintanable, but they allow you to do any offline calculations that the PIC does not have to do at runtime (the compiler will calculate at compile time).
15) When one is pretty sure of manual optimisation, setting compiler optimisation level to 0 or less optimisation may lead to smaller final code. That's because higher settings switch on optimisation mechanism that's efficient for some type of groups of statements (mostly expressions), but less efficient for others (mostly the well written ones). Credit for this tip - Janni.
16) When optimising your code by re-writing certain lines/sections (eg. because the assembly listing shows them to be inefficient, usually with unnecessary bank switching), you may be surprised to see your optimisation actually use up more code space than before, typically because the compiler optimiser for whatever reason gets tricked up. You will see this in the asm listing usually with multiple bank (RP0/1) switching. Try changing your optimisation levels and re-arranging your code, and sometimes you are better to leave that section of code un-optimised.
17) For the PRO version of the compiler, its OK to use the compiler scratch variables R0 - Rx (see listing) directly in your listing for your temporary variables as these are always in bank0 and can end up saving ROM and RAM. However be careful with this, I have found some corruption when using the internal variables, probably because their scope is global & the compiler makes some assumptions, so only do this when you know you won't be overwriting variables in another routine (eg. OK to do for top level routines, not OK for interrupt routines etc.) Credit for this tip - Janni.
18) If you only use a function once, put it inline rather that in a separate function. Your code won't be as modular but you will save space by not having to save variables passed to the function & making the call/return.
19) Pass complex types by reference not by value (eg. strings) into subroutines. This saves the compiler having to create copies of your variable and passing it around. Do not make functions of which the returned value is of a complex type. Instead use a "byref" parameter and put the result in there. Credit for this tip - Dany.
20) For simple IF THEN ELSE statements, you can save a couple of ROM instructions by putting your ELSE statements before the IF condition test and remove the ELSE so the default condition is always executed and only if the test is true will the alternative conditions be run. This will only work for simple statements like changing a variable depending on the outcome of the condition test but this happens a lot in PIC code. For example:
if IR_DETECT_PIN = IR_CARRIER then ' For the odd counter, if the IR Port is high, we have a '1'
IRAddr.0 = 1
else
IRAddr.0 = 0
end if
Can become (saving 1 instruction):
IRAddr.0 = 0
if IR_DETECT_PIN = IR_CARRIER then ' For the odd counter, if the IR Port is high, we have a '1'
IRAddr.0 = 1
end if
21) Use of WHILE WEND instead of FOR NEXT loops. Depending on your loop construct, the WHILE WEND construct is closer to the native ASM bit test then skip condition tests and in some circumstances compiles to less ROM instructions. I have not found this to be consistent and it seems to work better in simpler loops.
22) Use procedures instead of functions if you have no need to return a variable. In higher level languages we are used to using procedures and passing back return values to the calling routine, even if we don't use the return information. In PICs, a lot of the time you don't have the space or 'horsepower' to do anything with the returned value (like error management), so use procedures instead to save 4 - 6 instructions.
As a beginner in MikroBasic I have only scratched the surface with the above, and I'm sure more experienced MikroBasic developers can add a lot more tips and even expand (and correct!) my tips above. I'll post my particular routines I'm having difficulty with in a later post in this thread, and I'll compile (pun intended
) in this post the aggregate tips that people post, as a reference for readers.Please share your tips by replying to this thread!
Regards,
Dean
. As I don't use mE's compilers with PIC16s (prefer assembly there), I don't have a ready tip. If the general rule to place most frequently used variables in the same bank (preferably BANK0) doesn't help, try rearranging your statements.