XC8 Compilers - Discussion

[Beltza]

XC8 and C18 are two different beasts. XC8 is derived from HiTech PICC. Microchip adquired HiTech.

[jcddcjjcd]

I think my problems arise from not understanding how XC8 does things.
For example in converting my USB HID Bootloader I finally realized I was better using TBLPRT and TABLAT directly instead of using pointers.
When a ROM pointer is passed and the address is outside the normal programming range as when reading and writing userid and config words it changes the upper byte of TBLPTR to 20 from 30. Probably it assumes you would not want to do that.

Another sticky thing was that in my struct that holds the packet data relating to a bootloader operation I used uint24_t to allow for the 3bytes address but XC8 changed that to a 32 bit value even thought there was a union of 3bytes associated with it. That would have been alright if XC8 had shifted the rest of the struct up by one byte but it happily went along and my data[] was out by a byte.
By going back to unsigned short long everything was OK again except for the warning every time an unsigned short long is used.
I have plenty of unsigned short long the for the rest it works.

I have a question though.
Should I be using XC8 in CCI mode or not. Just changing it requires a whole bunch of other code edits.
Do people mainly use CCI?

Regards,
John.

[jcddcjjcd]

Well, all sorted now. Managed to make a HID bootloader out of the latest framework, the last one I could shrink to under 0x1000 was v2.1 and now they are up to v2.11 so that was pleasing.
Now that I have converted most of my projects over to XC8 and have more experience with it I do like it a lot more the C18 so it was worth the trouble.

Regards,
John.

[jnz]

I'm liking more than C18 for certain.

The trouble I'm having is that exceptionally few RTOS have coded to XC8.

[donhamilton]

What is the size of the xclm.old file ?

I think I deleted the wrong file. 

[Slasher]

Hi,

xclm.exe delivered with XC8 v1.33B is 924.160 bytes.

[Manuel]

Released Update to XC8 part support v1.33D:
http://ww1.microchip.com/downloads/en/DeviceDoc/xc8-v1.33D-part-support-windows-installer.exe

Manuel.

[yoda2020]

my complaint with the compiler is that it 'decides' what to compile in certain cases.   for no reason, when i was using a variable in a loop and loading values inside and reusing outside the loop and compiler (with and without optimisations enabled)  told me in the log file "variable unused" and did not compiled some lines of code, then i got weird behavior while debugging coff file..  does anybody have experienced that behavior?

This can get particularly annoying with routines using SPI where you need to ensure you clear SSPBUF by reading it then discarding the result. XC8 and Hi-Tech PICC both 'optimize' out code that has no further action. I think the suggestion here is to define the variable to we put SSPBUF into as volatile, I'll give that a try.

Thanks for the idea as it's much more elegant than my approach of adding an if(....) type structure after the SSPBUF read to fool the compiler. If anyone has a tried and trusted method for such circumstances I'd really love to hear it.

Dave

[Linko]

Dave,
in my code to manage UART I had a similar need: in case of error it becomes necessary to clear the RCREG by reading it.

I've used in the past the volatile variable approach, but I found later I could simply put a "RCREG;" statement, i.e. without any explicit assignment.
XC8 (1.33) compiler generates the correct opcode, a simple assignment to w register.

...
  2858                                   ;rs232.c: 162: RCREG;
  2859  001A36  50AE                  movf   4014,w,c   ;volatile
...



Linko

[jnz]

Dave,
in my code to manage UART I had a similar need: in case of error it becomes necessary to clear the RCREG by reading it.

I've used in the past the volatile variable approach, but I found later I could simply put a "RCREG;" statement, i.e. without any explicit assignment.
XC8 (1.33) compiler generates the correct opcode, a simple assignment to w register.

...
  2858                                   ;rs232.c: 162: RCREG;
  2859  001A36  50AE                  movf   4014,w,c   ;volatile
...



Linko

I'm still using volatile if the issue comes up, I just watch for "variable is not used" in the output... But that still doesn't mean this is a good compiler or a good option. Everyday, PIC is pushing me further into ARM's arms.

[Manuel]

Released Update to XC8 v1.34.
>>New license manager and installers

and to XC8 part support v1.34.
Released Update to MPLABX v2.35 and Released BETA MPLABX v3.0.

>> TOP, great WORK U DID! <<

I confirm the claimed: Comparison optimizations Code associated with equality and relational comparisons has been improved in many situations.... (in one of my case test the generated moved from 502 to 497...and the generated work :-) )

Manuel

[Cybernando]

xc8 v1.34 error USB hid framework !!!

Code:

microchip/mla/v2014_07_22/framework/usb/src/usb_device.c:25039: error: (800) undefined symbol "l11805"
(908) exit status = 1

with v1.33 all ok

[Manuel]

UPDATED: XC8 Compiler Part-Support Patch v1.34B

manuel.

[Manuel]

Seen XC8 3 compiler "issues"... and related workaround...

1) BIT vars are located on a different BANK for some processors even if there is still space in the main bank. This involve into BANK SWITCHING compiler instruction generation. So code is not optimized. It has been checked in the trial PRO mode.

workaround:
use UNION bits with a char. Then this char (bits) are placed on the same main BANK (if still space is present).
So this avoid unnecessary "buggy" BANK SWITCHING..... so you use less power...power optimized application.

2) condition:
if you use just 1 BANK....without bank switching.....the following sequence

WAIT_VREG:
   NOP();
   if(nDONE) goto WAIT_VREG;

become in generated ASM:

181  126                     l508:   
   182                          
   183                           ;main.c: 195: __nop();
   184  126  000                   nop
   185                          
   186                           ;main.c: 196: if(nDONE) goto WAIT_VREG;
   187  127  4A4                   bcf   4,5   ;FSR5=0, select bank0
   188  128  628                   btfsc   8,1   ;volatile
   189  129  B26                   goto   l508

the BOLD instruction is silly added by the compiler.....and it is generated by using the NOP(); instruction.

workaround:

generate a BIT var,

WAIT_TEMP:   
        BITS.BITs.DUMMY=0;
   if(nDONE) goto WAIT_TEMP;   

become in generated ASM:

181  128                     l506:   
   182                          
   183                           ;main.c: 197: BITS.BITs.DUMMY=0;
   184  128  452                   bcf   _BITS,2
   185                          
   186                           ;main.c: 198: if(nDONE) goto WAIT_VREG;
   187  129  628                   btfsc   8,1   ;volatile
   188  12A  B28                   goto   l506

now it's optimized!

3) xc8 TERRIBLE GENERATED CODE 1 MORE INSTRUCTION USED.
196                           ;main.c: 205: Mean=(TMR0&0x07);
   197  12F  201                   movf   1,w   ;volatile
   198  130  038                   movwf   _Mean
   199  131  C07                   movlw   7
   200  132  178                   andwf   _Mean,f

RIGHT OPTIMIZED GENERATED CODE :

 82                           ;main.c: 190: Mean=(TMR0&0x07);
    83  134  201                   movf   1,w   ;volatile
    84  135  E07                   andlw   7
    85  136  034                   movwf   _Mean

what a terrible compiler.....i PERSONALLY STOP COMPARING....IN A SOURCE I COMPILED THERE ARE SO MANY ISSUES ABOUT OPTIMIZZATION.....

how many further work around should have to find to such optimization issue?

for this reason i prefer always to write my own asm.

manuel.

[flo0319]

Hi manuel, can you please to tell me which xc8 version have you used for those examples? and also if you are using in optimization the option +space. Thanks 

[Manuel]

The "issue" is present on both 1.33 and 1.34 compilers.

The second compiler used for comparing....is not important...since the evidence is logically clear, the compiler leak in his management. and it's quite strange from my point of view. Strange is the fact that the compiler developer did not see such silly problems....or better did not tight the proper solutions ....

+space was not used.

Anyhow....just to complete the question, TWO more "ISSUEs"...that make me decide to avoid using XC8, and go on with ASM coding...

all vars are UNSIGNED CHAR !
apart for IO_IMAGE....that is a UNION bit.

XC8 "ISSUE" 1:

520                           ;main.c: 377: if(DB == IntCount) IO_IMAGE.PIN.PIN_B =0;
   521  1DA  217                   movf   _IntCount,w
   522  1DB  02F                   movwf   15
   523  1DC  193                   xorwf   _DB,w
   524  1DD  643                btfsc   3,2
   525  1DE  4B6                   bcf   _IO_IMAGE,5
   526                          
   527                           ;main.c: 378: if(DG == IntCount) IO_IMAGE.PIN.PIN_G=0;
   528  1DF  217                   movf   _IntCount,w
   529  1E0  02F                   movwf   15
   530  1E1  194                   xorwf   _DG,w
   531  1E2  643                   btfsc   3,2
   532  1E3  436                   bcf   _IO_IMAGE,1
   533                          
   534                           ;main.c: 379: if(DR == IntCount) IO_IMAGE.PIN.PIN_R =0;
   535  1E4  217                   movf   _IntCount,w
   536  1E5  02F                   movwf   15
   537  1E6  195                   xorwf   _DR,w
   538  1E7  643                   btfsc   3,2
   539  1E8  496                   bcf   _IO_IMAGE,4

15 instructions.

Right Compiling instead:

;main.c: 361: if(DB == IntCount) IO_IMAGE.PIN.PIN_B =0;
339                           ;main.c: 361: {
   340  1DD  20E                movf   _DB,w
   341  1DE  192                   xorwf   _IntCount,w
   342  1DF  643                   btfsc   3,2
   343  1E0  4B1                   bcf   _IO_IMAGE,5
   344                           ;main.c: 363: if(DG == IntCount) IO_IMAGE.PIN.PIN_G=0;
   345  1E1  20F                   movf   _DG,w
   346  1E2  192                   xorwf   _IntCount,w
   347  1E3  643                   btfsc   3,2
   348  1E4  431                   bcf   _IO_IMAGE,1
   349                           ;main.c: 364: if(DR == IntCount) IO_IMAGE.PIN.PIN_R =0;
   350  1E5  210                   movf   _DR,w
   351  1E6  192                   xorwf   _IntCount,w
   352  1E7  643                   btfsc   3,2
   353  1E8  491                   bcf   _IO_IMAGE,4

12 instructions.

It maybe seems silly 12 vs 15 is really important in optimizzation....

XC8 "ISSUE" 2:
520                           ;main.c: 377: if((DB - IntCount)==0) IO_IMAGE.PIN.PIN_B =0;
   521  1D2  213                   movf   _DB,w
   522  1D3  02A                   movwf   10
   523  1D4  06B                   clrf   11
   524  1D5  20B                   movf   11,w
   525  1D6  02F                   movwf   15
   526  1D7  217                   movf   _IntCount,w
   527  1D8  08A                   subwf   10,w
   528  1D9  02E                   movwf   14
   529  1DA  703                   skipc
   530  1DB  0EF                   decf   15,f
   531  1DC  10F                   iorwf   15,w
   532  1DD  643                   btfsc   3,2
   533  1DE  4B6                   bcf   _IO_IMAGE,5

Can it be possible no one have ever seen this? I can not believe !!!!
essentially a ZERO compare con unsigned bytes can not be converted in a real MATH sequence!!

hope more real improvement will be done on this compiler and not just adding processors....

Now the questions are:
- does XC8 compile same way for XLP processors? if so, why such effort to add XLP family processors if compiler then does not respect the investments done to realize XLP? (terrible)
-who produce a real optimized compiler for the MICROCHIP family processors?
-does both XC16 and XC32 have been developed with same core?

manuel.

[flo0319]

Hi again and many thanks for all those examples, will be very nice for me if you can add the c code for the last 2 issues (more interesting will be how they are declared ).
I am very interested in this compiler optimization problems and I have seen similar problems. I do not understand why it save the previous value of IntCount, are you use a re-entrant model? for which controller are you build this code?
Thanks a lot!

[Manuel]

Mchp Man!

Anyhow, NO REENTRANT.

some declares to workaround compiler ISSUES discussed:

pack in BANK0 if there is space....otherwise if vars declared as BITS goes on BANK1

typedef union
{
   struct
   {
         unsigned DID                   : 1;
         unsigned GOT_FIRST_T      : 1;
         unsigned DUMMY                 : 1;
        unsigned                       : 5;

   } BITs;   
   unsigned char BITS_ALL;
} BITS_VAL;

As requested:

unsigned char DB;
unsigned char DG;
unsigned char DB;
unsigned char IntCount;

STRANGE MANAGEMENT see the following with XC8 1.33 and 1.34 for two different COMPAREs:

   554                           ;main.c: 385: if(DB != 63) IO_IMAGE.PIN.PIN_B =1;
   555  1ED  C3F                   movlw   63
   556  1EE  193                   xorwf   _DB,w
   557  1EF  743                   btfss   3,2
   558  1F0  5B6                   bsf   _IO_IMAGE,5

if you compare to the  following you will notice one time not optimed...one time correct....a ZERO compare and  a non zero value compare....

   520                           ;main.c: 377: if(DB == IntCount) IO_IMAGE.PIN.PIN_B =0;
   521  1DA  217                   movf   _IntCount,w
   522  1DB  02F                   movwf   15
   523  1DC  193                   xorwf   _DB,w
   524  1DD  643                btfsc   3,2
   525  1DE  4B6                   bcf   _IO_IMAGE,5

I also checked just for my personal interest many other interesting ISSUES....and till XC8 is not as I would like it could be....I will only go on writing my own ASM.

Anyhow, PIC12F5xx checked....but same issues apply to many other target processor.

Hope can help someone to decide direction when deciding to do investments...fortunately the trial exhist.

manuel.

[ptr]

@Manuel

did you do this tests when the compiler is installed as a demo?

If yes please read here:
http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/

[Manuel]

No, as time limited PRO mode.

I checked even FREE mode in advance just to compare both results...and FREE is FREE and PRO is PRO, but the PRO mode does not satisfy obvious optimizations. This is the question. And consider that it should be so easy to adjust the PRO mode to be really efficient.... I do not understand why noone ever considered or discussed really those questions in deep detail. I would have expected XC8, since the development stared many years ago deriving from HI-TECH compiler, could be more efficient, cosidering even that the old HI-TECH itself is more efficient in general for the supported processors....

Manuel.

[Manuel]

Got the question about unoptimized compiler...

At a certain point developers decided to use a resister variable located in BANK0 (I saw) as temporary storage in place of the W register..
This is suitable for processors where INT have to be managed in a "certain way"...but for code where no interrupt are used..this management is a BAD way to get optimized code...

This is mainly the question I think.

Related to BIT question.... an ODD BANKING is present starting from 9.60PL4. Anyhow you have the wayout explained previously.

Hope this can help for further development including compiler developer too.

I know not all is easy to be done but at least managing exceptions can help many developers i think.....so I go on with ASM.

take care,
Manuel.

[Manuel]

UPDATED: XC8 Compiler Part-Support Patch v1.35B

manuel.

[Catcatcat]

MPLAB® XC8 Compiler v1.36
medicine is working!

[nagkiller]

Where is medicine???

[Thiru09]

Where is medicine???

http://www.sonsivri.to/forum/index.php?topic=44014.0