PIC18 Optimization

[EECEWOLF]

Has anyone seen the code generated for an if(...) statement in the pic18 series? It seems like the compiler generates the same code as if it were a pic16 series. They are not taking advantage of the newer instructions.
___________________________
This message was ported from CCS's old forum
Original Post ID: 13051

[Neutone]

:=Has anyone seen the code generated for an if(...) statement in the pic18 series? It seems like the compiler generates the same code as if it were a pic16 series. They are not taking advantage of the newer instructions.

I have looked at it and think their is an issue with else statements. The compiler will generate goto statements that goto other goto statements. I think that as part of the final pass of optimization the this should be checked for and optimized.

I don't see any other room for improvement.
___________________________
This message was ported from CCS's old forum
Original Post ID: 13053

[Tomi]

:=Has anyone seen the code generated for an if(...) statement in the pic18 series? It seems like the compiler generates the same code as if it were a pic16 series. They are not taking advantage of the newer instructions.

Of course not . Currently a 18F compiler's main task is to help us to migrate from 16F series to 18F chips. Mine does it very well
I hope CCS will continue developing about 18Fxx2(0) parts, especially:
1. Ability to use pointers to const structures. Currently the compiler uses the old method (call a function, calculate the address and read data, inherited from 16F) with that ugly preamble just before the data table. It would be better to store the addresses at compile time and to read direct ROM addresses by the TBLRD*(+/-) instructions. Of course CCS C already uses this instruction but the _access_ of the const starts with a CALL instead of a simple read. I have posted a code snippet to demonstrate how to retrieve a string from a dedicated ROM address with 18F series.
2. 18Fxx20 brings up an additional feature: the internal 21-bit address bus (found also in 18Fxx2, used only for internal ROM) is wired out from the PIC so we were able to connect an external RAM to the PIC. Then we could read or write this RAM by single instructions (TBLRD*, TBLWT*) so it would be easy to use the external RAM as memory for both code and data.
Currently I use something like this:

void ReadStructure(void *p, int32 address, unsigned long length)
{
#byte addressL = address
#byte addressH = address+1
#byte addressU = address+2
#byte pH = p
#byte pL = p+1

TBLPTRU = addressU;
TBLPTRH = addressH;
TBLPTRL = addressL;
FSR1L = pL;
FSR1H = pH;
do {
#asm
TBLRD*+
#endasm
POSTINC1 = TABLAT;
} while (--length);
}

void WriteStructure(void *p, int32 address, char length)
{
#byte addressL = address
#byte addressH = address+1
#byte addressU = address+2
#byte pH = p
#byte pL = p+1

TBLPTRU = addressU;
TBLPTRH = addressH;
TBLPTRL = addressL;
FSR1L = pL;
FSR1H = pH;
do {
TABLAT = POSTINC1;
#asm
TBLWT*+
#endasm
} while (--length);
}

Usage:
unsigned long lvar;
float fvar;

ReadStructure(&lvar,0x000000,sizeof(unsigned long));
WriteStructure(&fvar,0x000002,sizeof(float));

It would be nice if we were able to declare variables in that RAM. A compiler knows -at compile time- the addresses and the size of the variable.
And -as the final step- we could have a software stack at top of the RAM (e.g. 1kbyte from the 2MB address space ).

Well... Maybe in the next year... ;)
___________________________
This message was ported from CCS's old forum
Original Post ID: 13056