In fact, I even used to hate it due to the poor quality of the C compilers. When I started to program PICs microcontrollers in 1998 there was not too many options to program PICs in C. As far as I remember, only Hi-Tech, IAR and CCS had compilers — not even Microchip has his own one — and they were quite horrible compiling. But the fault was not in the compilers manufacturers, but in the PIC core architecture. Those cores were so simple that it was not easy no make a C compiler for them. Few memory, scarce resources, small instructions set, few addressing modes… Anyway, who needs a C compiler with such simple architectures? Two years ago Microchip bought the Hi-Tech company and renamed their Picc compiler as XC8. With this movement, Microchip provide to their clients a cheap and decent C compiler as their old and deprecated C18 compiler was — in my opinion — plenty of bugs and not worthy to work with. I still use ASM to program the PIC12 and PIC16 family. However, I program the PIC18 devices in C but I often had to dive into the asm of the generated binary to optimize it. In those optimizations I have seen weird things made by compilers and I have been long time wanting to write about it. Today I am only going to write shortly about how the free mode of the XC8 compiler bloats the binary to make the Pro version look more efficient. I have been working for the past week in a new design and as my most important requirement is the size of the PCB, I decided to use the new PIC 12F1840. The firmware has a time-critical section were an algorithm is executed to measure the frequency of a signal. Running at 16MHz, I calculated I had 120 instructions cycle to execute the algorithm: getting the CCP1 comparator value, checking if it has only a small deviation from the past captured values, calculating the median and storing it in a buffer. Could the C compiler be efficient enough to make the algorithm to run in just those 120 cycles I had? I estimated between 30 and 40 cycles if I code it in ASM, so I was asking for a C compiler just 25% or 33% as efficient as programming in assembly. Well… the answer is NO. The XC8 was far from being efficient enough to fit the algorithm. The generated code was running in 230 instruction cycles. At the end, I had to check the disassembly listing and replace those poor optimized C sentences with ASM blocks. Time before Microchip bought Hi-Tech, Hi-Tech wanted to release a free version of their PICC compiler the current XC8. They decided to license a version of the compiler without any optimization activated, so their Lite free version was fully functional but not efficient in terms of size and speed. Even without the optimizations, the Lite version was very attractive specially to hobbyist and small companies who could prefer to use a more powerful PIC instead of paying the license to have a more efficient compiler. To encourage the purchase of a Pro license, Hi-Tech decided to make the gap between the Lite and Pro version even bigger by inserting garbage in the generated binary file when using the Lite mode. A simple example The next examples are run on MPLABX 1. The first column is the address location, the second one is the op-code and the third is the mnemonic code This code is 10 instructions long and takes 22 instruction cycles to execute. This is how I would do it: LSRF maxDev , F ; Just 5 instructions and 5 cycles. Half size and less than a quarter of the time needed to execute it. What is wrong with the ASM generated by the XC8 compiler? This is the correct way to do write it if you are not worried about the speed but about the code size and you are going to rotate the register at least 5 times. If you rotate it less than 5 times, it is smaller to just
