What is a mixed mode 8, 16 and 32 bit optimising compiler? The 8, 16 and 32 refers to the binary width of the numbers the compiler can generate code for. This is like specifying the number of digits a calculator has. Roughly this translates to: 8 bits 2 decimal digits 16 bits 4 decimal digits 32 bits 9 decimal digits The exact range of numbers that can be stored in 8, 16 and 32 bit wide variables is: unsigned 8 bit 0   to   255 signed 8 bit -128   to   +127 unsigned 16 bit 0   to   65535 signed 16 bit -32768   to   +32767 unsigned 32 bit 0   to   4,294,967,295 signed 32 bit -2,147,483,648   to   +2,147,483,647 IEEE 754 32 bit float see floats When the compiler generates code to perform arithmetic on 8 bit numbers, these numbers must fit in the memory the processor uses to store them. If the processer trys to store the number 300 in an 8 bit memory location part of the number will be lost. To perform arithmetic on numbers greater that 255 the compiler must generate code that performs arithmetic on 16 bit numbers. The number 300 will not fit in an 8 bit location but it will fit in a 16 bit location. Sometimes a 16 bit number is too small to work with. In these circumstances 32 bit numbers can be used. If a 32 bit number can handle such big numbers, numbers bigger than we are ever likely to need, why bother having 8 bit and 16 bit numbers as well? The reason is that the PIC processor can only handle 8 bit numbers efficiently. 16 bit numbers require between 2 and 5 times as much work to process on the PIC (depending on the exact operation). 32 bit numbers require between 4 and 20 times as much work. Clearly if an 8 bit number will do the job, it is pointless using a 16 or 32 bit number which will consume processor time and memory needlessly. Where does mixed mode come into this? The XCSB compiler has been designed to cope with combinations of 8, 16 and 32 bit numbers as efficiently as it can. This meens that when adding an 8 bit number to a 16 bit number, the compiler will take advantage of the fact that the 8 bit number will completely fit in the PIC hardware register and not bother with the missing part (the imaginary top 8 bits). The XCSB compiler takes similar advantage when adding an 8 bit number to a 32 bit number or when adding a 16 bit number to a 32 bit number. Some compilers insist on promoting the smaller number so that it is the same size as the larger of the two numbers being used and then performing the operation on these two large numbers even when the most significant part of the result will be lost. This is a simple solution for the compiler writer but leads to completely unnecessary code being produced and executed by the PIC. Ok, so what is an optimising compiler? An optimising compiler is one that converts high level source code into executable machine code and arranges it in such a way that it executes as quickly as possible OR requires as little memory as possible. The XCSB optimising compiler can produce code that is almost as optimal as that produced by an expert assembler programmer. Using the code produced by an expert assembler programmer as a meter, the XCSB compiler has been shown to produce code which deviates from optimal (in speed) by between 0% and 20% (tending toward 0% on simple common code and 20% on very complex rare code) This compares vary favourably with other optimising compilers and is unbeliveably fast compared to non-optimising compilers which easily produce code that deviates by more than 200% from optimal.   the following XCSB source code proc inline clear_bit(ubyte *ptr, ubyte id) *ptr = *ptr & ~(1 << id) endproc proc main() clear_bit(&PORTA, 3) endproc is compiled into just one native PIC instruction bcf PORTA, 3