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:
The exact range of numbers that can be stored in 8, 16 and 32 bit wide variables is:
|8 bits||2 decimal digits|
|16 bits||4 decimal digits|
|32 bits||9 decimal digits|
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
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.
|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|
32 bit float
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
the following XCSB source code
proc inline clear_bit(ubyte *ptr, ubyte id)
*ptr = *ptr & ~(1 << id)
is compiled into just one native PIC instruction
bcf PORTA, 3