Firewing

OK, lets try again. Download the latest Firewing BETA and also XC16 toolsuite from here:

http://www.firewing.info/pmwiki.php?n=Firewing.Download
http://www.firewing.info/pmwiki.php?n=FirewingUser.XC16Toolsuite

This should enable you to use XC16 1.20 with Firewing. I have noticed the *.hex file generated by XC16 1.20 is much larger than 1.11. For example, one program I tested against was 25K for 1.20 and 20K for 1.11. If you can work with 1.11, I would probably stick with it. Either way, the "tsMicrochip16.ini" file outlined in an earlier post will enable you to switch XC16 versions at any time.

Jerry - the new BETA download should fix the target selections problem you identified last night.

Let me know how it goes...

Dave

>> For example, one program I tested against was 25K for 1.20 and 20K for 1.11
Boy, that's a pretty big change. Did you happen to notice why it grew so much?
Must be yet another "improvement".


One other thing I noticed in xc16 v1.20 is that in the device .h header files there is now
a '#define' for each of the SFR registers and bit structures...

Code: Select all

#define TBLPAG TBLPAG
extern volatile unsigned char TBLPAG __attribute__((__sfr__));
#define PSVPAG PSVPAG
extern volatile unsigned char PSVPAG __attribute__((__sfr__));
#define RCOUNT RCOUNT
extern volatile unsigned int  RCOUNT __attribute__((__sfr__));


In the readme they mention

Code: Select all

This release provides pre-processor definitions for each SFR when xc.h is included; for example:

        #include <xc.h>

        #ifndef T1CON
        #error Please select a device that contains Timer 1
        #endif
     
        main() {
          T1CONbits.TON;
          /* and so on ... */


I've never seen this approach before, and I'm not sure I see the benefit. While it does let
you check to see if a register exists, it doesn't help much with the fact that they sometimes
add/change/move bits around inside the registers from device to device.

I didn't see anywhere in the library code that they actually use this type of check. Besides,
if you didn't have the #define and the #ifndef test, the compiler will complain as soon as it
sees T1CONbits if it doesn't exist.

Am I missing something?

> Boy, that's a pretty big change. Did you happen to notice why it grew so much?

I've need really dug around yet, so cannot say why - but I would be interested to know why. It's pretty consistent though. That is, all my test programs are significantly larger with 1.20.

> '#define' for each of the SFR registers and bit structures...

That's interesting. Like you, I can only see this useful for testing if a register exists - but why? Well, they may have something in the pipeline and have released some of the code needed for future changes. I've done this myself. Rather than release a major change at once, you release some of the underlining changes over time. It's easier to manage the code "breaks" this may, before making any official announcements. This is all speculation though - on it's own, I cannot see why they have made these additions. However, given the significant increase in code size and also by the fact the compiler broke with some asm clobbering that previously worked, the changes in 1.20 must be significant?

David,

I just downloaded beta 8 and I still get the same error.
But the previous work around using XC16 V1.11 works just fine.

and you have downloaded the latest toolsuite? Can you double check please as I'm 99.99% certain I have removed all offending code. If the problem persists, you need to give an example of the code that generates the error.

Sorry, David reading comprehension is not strong suit today.

It works just fine once I downloaded the new XC16 toolsuite.
Thanks again

Keith

Update

I built some code today using the xc16 1.20 toolsuite and it's definitely not working correctly in my opinion. When I build with xc16 1.11 the code works as expected. For the time being, I would personally stick to 1.11 as the Firewing xc16 toolsuite. Fortunately, you can have both xc16 1.11 and 1.20 installed on your machine so you can switch between the two as required. See the "Using Different Versions of XC16" section of this wiki article:

http://www.firewing.info/pmwiki.php?n=FirewingUser.XC16Toolsuite

If you do not have xc16 1.11 installed, there is a version here:

http://ww1.microchip.com/downloads/en/DeviceDoc/xc16-v1.11-windows-installer.exe

That's interesting... from the readme for V1.20 not all that much supposedly changed, other than those useless "#define REG REG" statements.
I do see that they added a new C fixed-point datatype and a new linker option or two.

Do you happen to know if any of the examples show v1.20 failing vs 1.10 working? I'd be curious to see the diff...

Hi Jerry

> from the readme for V1.20 not all that much supposedly changed, other than
> those useless "#define REG REG" statements. I do see that they added a new C fixed-point
> datatype and a new linker option or two.

With that in mind, building "progLCDPlus.bas" with give a 5K difference in code size between 1.11 and 1.20 (1.11 being the smallest) which seems awfully high given that only a few things have changed.

> Do you happen to know if any of the examples show v1.20 failing vs 1.10 working? I'd be curious to see the diff...

Yes, you can see the problem with "progLCDPlus.bas", supplied with Firewing. If you enable the "SetRTC()" function 1.20 will fail to display the correct time. Building in native Firewing or xc16 1.11 and it all works perfectly, all of the time. Please do let me know if you see the same thing. I've not dug any deeper but there is a problem and that's why, at the moment, I would recommend xc16 toolsuite users to stick with 1.11 if possible (and it generates smaller code). As you know Jerry, the xc16 Firewing toolsuite will generate lots of (but very simple) "C" code so why this should suddenly fail is all rather strange?

I would welcome your input...

I played around with this a little bit and from what I see they definitely changed SOMETHING in V1.20

It seems that they changed the register allocation, and it ends up adding more code to pretty much each statement. It looks like it tries to avoid using W0. Here's a little snip of the first few lines of DecToStrFormat when compiled using MPLAB as an example...

V1.11

Code: Select all

0000030e <_PROC_OL_0_DecToStrFormat_0>:
     30e:   00 00 fa       lnk       #0x0
     310:   0d 08 a8       bset.b    0x80d, #0x0
     312:   41 80 20       mov.w     #0x804, w1
     314:   91 40 78       mov.b     [w1], w1
     316:   0a c8 bf       mov.b     0x80a, WREG
     318:   80 cf 50       sub.b     w1, w0, [w15]
     31a:   03 00 36       bra       LEU, 0x322
     31c:   0a c8 bf       mov.b     0x80a, WREG
     31e:   04 e8 b7       mov.b     WREG, 0x804
     320:   01 00 37       bra       0x324

00000322 <.L18>:
     322:   00 00 00       nop       

00000324 <_ENDIF_1>:
     324:   c1 00 80       mov.w     0x18, w1
     326:   04 c8 bf       mov.b     0x804, WREG
     328:   00 80 fb       ze        w0, w0
     32a:   00 80 40       add.w     w1, w0, w0
     32c:   c0 00 88       mov.w     w0, 0x18
     32e:   00 05 eb       clr.w     w10
     330:   0a 56 78       mov.b     w10, [w12--]


V1.20

Code: Select all

00000312 <_PROC_OL_0_DecToStrFormat_0>:
     312:   00 00 fa       lnk       #0x0
     314:   0d 08 a8       bset.b    0x80d, #0x0
     316:   45 80 20       mov.w     #0x804, w5
     318:   95 42 78       mov.b     [w5], w5
     31a:   a4 80 20       mov.w     #0x80a, w4
     31c:   14 42 78       mov.b     [w4], w4
     31e:   84 cf 52       sub.b     w5, w4, [w15]
     320:   06 00 36       bra       LEU, 0x32e <.L18>
     322:   a4 80 20       mov.w     #0x80a, w4
     324:   14 42 78       mov.b     [w4], w4
     326:   00 02 fd       exch      w0, w4
     328:   04 e8 b7       mov.b     WREG, 0x804
     32a:   00 02 fd       exch      w0, w4
     32c:   01 00 37       bra       0x330

0000032e <.L18>:
     32e:   00 00 00       nop       

00000330 <_ENDIF_1>:
     330:   c5 00 80       mov.w     0x18, w5
     332:   44 80 20       mov.w     #0x804, w4
     334:   14 42 78       mov.b     [w4], w4
     336:   04 82 fb       ze        w4, w4
     338:   04 82 42       add.w     w5, w4, w4
     33a:   c4 00 88       mov.w     w4, 0x18
     33c:   00 05 eb       clr.w     w10
     33e:   0a 56 78       mov.b     w10, [w12--]


Both compilers are based on the same GCC version, but 1.11 definitely produces better code. I tried to see if maybe there was some sort of optimization change that might "fix" this, but as soon as I did that the compiler changed the .LST file output and refused to produce the same mixed src/asm output! GRRR!!

I've no clue what this "fixes", but an extra 5K in a 20K program is ridiculous. It's not like there's some extra library code either, so it would just continue to grow and grow.

I give up. I don't have the energy to try and figure out what Microchip does these days.