home download demos platforms restrictions help

 

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 bits2 decimal digits
16 bits4 decimal digits
32 bits9 decimal digits

The exact range of numbers that can be stored in 8, 16 and 32 bit wide variables is:

unsigned 8 bit0   to   255
signed 8 bit-128   to   +127
unsigned 16 bit0   to   65535
signed 16 bit-32768   to   +32767
unsigned 32 bit0   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


 
home download demos platforms restrictions help