Author Topic: Has anyone tried the XC8 PRO compiler with AVRs?  (Read 15271 times)

0 Members and 1 Guest are viewing this topic.

Offline IonizedGearsTopic starter

  • Regular Contributor
  • *
  • Posts: 248
  • Country: us
Has anyone tried the XC8 PRO compiler with AVRs?
« on: July 22, 2018, 11:12:58 pm »
I was looking through Microchip's website and I realized that XC8 PRO ( the not-free and expensive version of Microchip's 8 bit compiler) is a thing for AVR with the new AVR support in MPLAB X. I find it hilarious because no one is going to buy XC8 pro for something that already has pretty good compilers. However, it got me thinking. How does the XC8 compiler compare in terms of optimizations? Does microchip plan on dropping support for the free AVR compilers with Atmel Studio and not including them in MPLAB X in hopes that people are forced to buy their stupid expensive compilers if they want better optimizations? When I first heard that AVR support was coming to MPLAB X was great since it meant a proper IDE for AVR in Linux but now it's a little terrifying.

/Begin rant

Let's face it, Microchip should release their XC8 compilers and stick to the hardware business. I'm sure they have made enough money back from their purchase of the HI-TECH C compilers already. I also don't think that "go mess with assembly if you want optimizations" is a good answer either since you would expect a hardware manufacturer to make their hardware as accessable to everyone as possible. Companies where a few thousand dollars for a compiler is a formality are exempt from this rant, although they kind of perpetuate the problem by forking over the cash.

Don't get me wrong, I've only dealt with PICs so I am by no means an AVR fan boy. It's just kind of frustrating to see this and to think that Microchip might possibly be trying to force AVR into this, too.

/End rant

Sorry for any errors, typed this out with my phone. IX

I am an EE with interests in Embedded, RF, Control Systems, and Nanotech.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #1 on: July 23, 2018, 04:38:49 am »
I figured they would not do this with the avr side, but it looks like its happening. It looks like they will try to move the whole inventory over to MPLABX over time. I assume the sam parts will eventually have restrictions also (when used in MPLABX).

The bright side is there is nothing they can do to prevent anyone from modifying the gcc compilers to allow all optimizations.

They do not release the source to the avr compiler (in XC8 v2.00) as far as I can see, but they will have to eventually.

Even if they do not, it only takes any half-a-brain person (like myself) to modify the compiler (without any guilt)-
/opt/microchip/xc8/v2.00/avr/libexec/gcc/avr/5.4.0/cc1  - file offset 0xf3d210  - change FFFFFFFFFFFFFFFF to 0200000000000000 - you are now a PRO

 
The following users thanked this post: IonizedGears

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 722
  • Country: ch
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #2 on: July 23, 2018, 06:47:27 am »
? When I first heard that AVR support was coming to MPLAB X was great since it meant a proper IDE for AVR in Linux but now it's a little terrifying.

there are proper IDEs on Linux to work with the avr-gcc; there is codeblocks and there is eclipse, what more does somebody need.
 

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 722
  • Country: ch
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #3 on: July 23, 2018, 07:50:52 am »
No issues between the not very recent avr-libc 2.0.0 and the newest gcc 8.1? In the past that didn't always work out well. I'm still stalling with the 4.9 avr-gcc coming with debian jessie
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #4 on: July 23, 2018, 01:40:09 pm »
Quote
Does XC8 AVR even allow C++
Although they have the c++ compiler executables included, I don't think they have it supported via the ide and do not include any c++ libraries.

I have no idea of gcc versions, but this what version it shows-
avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.2_66) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.


 

Offline IonizedGearsTopic starter

  • Regular Contributor
  • *
  • Posts: 248
  • Country: us
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #5 on: July 23, 2018, 04:54:36 pm »
? When I first heard that AVR support was coming to MPLAB X was great since it meant a proper IDE for AVR in Linux but now it's a little terrifying.

there are proper IDEs on Linux to work with the avr-gcc; there is codeblocks and there is eclipse, what more does somebody need.

There are still a ton of features in MPLAB X and Atmel studio that you don't really get without at least a ton of hassle like debugging and simulation.
I am an EE with interests in Embedded, RF, Control Systems, and Nanotech.
 

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 722
  • Country: ch
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #6 on: July 23, 2018, 05:00:14 pm »
before Microchip bought Atmel, the AVR world was perfectly fine without MPLAB
« Last Edit: July 23, 2018, 05:19:00 pm by HB9EVI »
 

Offline IonizedGearsTopic starter

  • Regular Contributor
  • *
  • Posts: 248
  • Country: us
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #7 on: July 23, 2018, 05:23:17 pm »
I figured they would not do this with the avr side, but it looks like its happening. It looks like they will try to move the whole inventory over to MPLABX over time. I assume the sam parts will eventually have restrictions also (when used in MPLABX).

The bright side is there is nothing they can do to prevent anyone from modifying the gcc compilers to allow all optimizations.

They do not release the source to the avr compiler (in XC8 v2.00) as far as I can see, but they will have to eventually.

Even if they do not, it only takes any half-a-brain person (like myself) to modify the compiler (without any guilt)-
/opt/microchip/xc8/v2.00/avr/libexec/gcc/avr/5.4.0/cc1  - file offset 0xf3d210  - change FFFFFFFFFFFFFFFF to 0200000000000000 - you are now a PRO

I'll admit I've been looking at how to crack XC8 for pics. I tend not to care that much about piracy at this level since it's clear students and hobbyists are not in the target audience so it changes nothing for Microchip. Their real target audience probably wouldn't even mess around with cracks for legal and support reasons.

Also, I looked into cc1.exe on windows and the file offset does go up to 0xf3d210. It ends at around 0x00d6b5ff.
I am an EE with interests in Embedded, RF, Control Systems, and Nanotech.
 

Offline IonizedGearsTopic starter

  • Regular Contributor
  • *
  • Posts: 248
  • Country: us
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #8 on: July 23, 2018, 06:42:23 pm »
before Microchip bought Atmel, the AVR world was perfectly fine without MPLAB

Atmel had Atmel Studio and I'm sure the world was perfectly fine before medicine, too. The benefits an IDE gives you are great and anything that lets me focus on my code more than trying to get the tools working is what I will use.
I am an EE with interests in Embedded, RF, Control Systems, and Nanotech.
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #9 on: July 23, 2018, 07:01:16 pm »
i like MPLAB X waaaaaaaaay better
altough intellisense is hard to beat, and frankly the autocomplete in netbeans is very basic.

on the subject of compilers, have you tried comparing the binary before and after?
To be frank i would be surprised if you noticed the difference.

First, with PICs there's not much you can do anyway, except perhaps more use of the INDF registers for pointers, arrays and such. In the past there was the nasty habit of multiple MOV or other crap like that, the famous """"added bloat"""", which is not there anymore. Now they try to kill the performance of builtin math as much as possible, but other than that the comparison between my code with free optimization (or level "1" in XC8 2.0, which mimics -O1) and pro optimization was always of a couple RAM locations and a handful of instructions at most.
That can't make that much of a difference, if i'm trying to squeeze every possible byte out of a PIC16/18 i use assembly.
Also because the architecture is what it is.

For AVR i have no idea as the only ones i care about are ATSAM, but have you ever actually used more optimizations than -O1? there nasty things start to happen because the compiler things he's too smart.. or better put you are letting him being too smart. and debugging start becoming a nightmare.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #10 on: July 23, 2018, 07:33:23 pm »
Quote
Also, I looked into cc1.exe on windows and the file offset does go up to 0xf3d210. It ends at around 0x00d6b5ff.
For Windows-
C:\Program Files (x86)\Microchip\xc8\v2.00\avr\libexec\gcc\avr\5.4.0\cc1.exe  - file offset 0xBF5890 - change FFFFFFFFFFFFFFFF to 0200000000000000

Now we get to add the confusion of XC8 the pic version, or XC8 the avr version- I guess one will have to refer to XC8-PIC or XC8-AVR. I could care less about the XC8 pic version as far as optimization is concerned, as it does an ok job with what we get for free, and we know that is the deal with that type of software. With the gcc compilers,  I'm going to use to my advantage the same license mchp uses to its advantage.

I suspect the -Os optimization is a bigger deal with avr.
 
The following users thanked this post: oPossum

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 722
  • Country: ch
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #11 on: July 23, 2018, 08:27:20 pm »
well, then I'll give it a try and compile the toolchain manually again; I actually didn't bother much anymore in the recent time studying the listings, I did that much more in detail when I still worked with sdcc on the pics, since the binaries often ended up exceeding the flash size; I never had similar issues on the avr, so I just went on; I had very well some issues with the optimazation when working on the code for a frequency counter, I suspected the gcc as well and tried several versions, but it turned out to not be the point
 

Offline Eturtle

  • Newbie
  • Posts: 6
  • Country: de
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #12 on: September 06, 2018, 08:27:30 pm »
maybe lets skip the call to avr_get_license at all

Code: [Select]
cd /opt/microchip/xc8/v2.00/avr/libexec/gcc/avr/5.4.0

printf '\x90\x90\xc7\x05\x10\x62\xf8\x08\x02' | dd of=cc1 bs=1 seek=8170722 count=9 conv=notrunc
printf '\x90\x90\xc7\x05\x90\x3b\xec\x08\x02' | dd of=lto1 bs=1 seek=7575626 count=9 conv=notrunc

 

Offline bson

  • Supporter
  • ****
  • Posts: 2265
  • Country: us
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #13 on: September 07, 2018, 03:11:20 am »
Dump Microchip and use MSP430 and ARM.

TI funds work on gcc for their processors, and contributes changes back to the mainline.
TI doesn't try to charge license fees for gcc.
TI doesn't refuse to distribute source code for what they ship in violation of their agreement with the FSF and copyright holders (including me, since I worked on gcc in the early 90s).

Basically, Microshit has built a business around fraud, deception, and the work of others.

Their processors are crap anyway, so no loss.
 
The following users thanked this post: Yansi

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #14 on: September 07, 2018, 09:13:38 am »
Quote
maybe lets skip the call to avr_get_license at all
Let a Windows user try those commands :)

 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #15 on: September 08, 2018, 04:27:39 am »
This is a bit outrageous to me, applying license limitations to stock GCC. AVR support has long been mainlined in stock GCC, and I do believe people will be backporting new chip support even if Microchip decided to stop contributing (since the AVR part of XC8 is still GCC.)

We should just keep modifying XC8/AVR, XC16 and XC32, those are licensed only under GPL not whatever license Microchip is showing you at installation simply because they are based on GCC. As of XC8/PIC, start contributing to SDCC.
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #16 on: September 08, 2018, 05:09:42 am »
Dump Microchip and use MSP430 and ARM.

TI funds work on gcc for their processors, and contributes changes back to the mainline...

Basically, Microshit has built a business around fraud, deception, and the work of others.

Their processors are crap anyway, so no loss.
I few years ago I got several dev boards to evaluate different MCUs, including the MSP430. It worked OK, but the chip seemed complicated to set up and TI's documentation was confusing (as usual for them). So I shelved it and continued using PICs. But hey, it's been a while so maybe they are better now?

Microshit's processors are crap anyway, so no loss - which means I must be able to get a TI MCU which does the same job. Unfortunately it seems I don't have the skills to navigate TI's website because I couldn't find what I wanted. So I tried Digikey, who list 3,913 different MSP430s. Sadly I struck out there too - apparently no MSP430 comes in a SOT23 package and can operate directly off a single cell Lipo.  Guess I will just have to stick with Microshit!
 
BTW,
Quote
NOTE TO MSP432 DEVELOPERS

MSP432-GCC-OPENSOURCE is deprecated and will not be updated in the future.

Please note: The free MSP430 GCC compiler does not provide the code size and performance advantages of the optimizing TI compiler found in Code Composer Studio. On average the TI compiler often provides about a 15% code size and performance improvement, as compared to using the free GCC compiler
 

Offline Whales

  • Super Contributor
  • ***
  • Posts: 1899
  • Country: au
    • Halestrom
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #17 on: September 08, 2018, 05:41:04 am »
This is a bit outrageous to me, applying license limitations to stock GCC.

Wait wait wait -- I don't use MC software (I stick to avrgcc and sdcc), so I'm not sure what's going on here.  Can we confirm if MicroChip is distributing a derivative of GCC (a) without a copy or notice about the GPL and/or (b) with 'further restrictions' on its distribution or use?

From https://www.gnu.org/licenses/gpl-3.0-standalone.html :

Quote
  6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions.  You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.

I have no power to enforce any licensing, but this affects whether or not I'm going to keep using MC (AVR) devices.  I'm hoping it's not true.
« Last Edit: September 08, 2018, 05:50:00 am by Whales »
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #18 on: September 08, 2018, 06:28:33 am »
This is a bit outrageous to me, applying license limitations to stock GCC.

Wait wait wait -- I don't use MC software (I stick to avrgcc and sdcc), so I'm not sure what's going on here.  Can we confirm if MicroChip is distributing a derivative of GCC (a) without a copy or notice about the GPL and/or (b) with 'further restrictions' on its distribution or use?

From https://www.gnu.org/licenses/gpl-3.0-standalone.html :

Quote
  6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions.  You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.

I have no power to enforce any licensing, but this affects whether or not I'm going to keep using MC (AVR) devices.  I'm hoping it's not true.
The XC8-AVR contains a copy of AVR-GCC with Microchip XC8 license check (likely the same license check as used in XC16/XC32.) xc8/v2.00/pic is now based on LLVM/clang.

As far as I know that AVR-GCC is stock mainline GCC. XC32 is modified from MIPS-GCC. XC16 is a brand new backend developed for GCC.
« Last Edit: September 08, 2018, 06:30:07 am by technix »
 

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #19 on: September 08, 2018, 09:08:10 am »
This is a bit outrageous to me, applying license limitations to stock GCC.

Microchip are not the first to abuse GPL in this way, it is similar to "tivoization". Probably there is a clause buried somewhere in the Microchip T&Cs which say FOSS components may be covered by separate license to MC license, and there is some convoluted way to get the modified source.

It is quite hard to stop determined thieves like MC stealing FOSS, the GPLv3 attempted to tighten things up at the expense of becoming too "viral" for some cases. Most users don't care and some even think it is ok to steal FOSS, since it is "free beer".
Bob
"All you said is just a bunch of opinions."
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #20 on: September 08, 2018, 10:59:59 am »
This is a bit outrageous to me, applying license limitations to stock GCC.

Microchip are not the first to abuse GPL in this way, it is similar to "tivoization". Probably there is a clause buried somewhere in the Microchip T&Cs which say FOSS components may be covered by separate license to MC license, and there is some convoluted way to get the modified source.

It is quite hard to stop determined thieves like MC stealing FOSS, the GPLv3 attempted to tighten things up at the expense of becoming too "viral" for some cases. Most users don't care and some even think it is ok to steal FOSS, since it is "free beer".
I wonder if getting FSF involved in this would ever work? It is their work that MC decided to put a license check on, especially for AVR-GCC component in XC8 v2.00 which is literally unmodified, stock AVR-GCC and AVR-libc.
 

Offline Whales

  • Super Contributor
  • ***
  • Posts: 1899
  • Country: au
    • Halestrom
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #21 on: September 08, 2018, 01:27:29 pm »
Eek.

I'll bolden a bit of what I quoted before:

Quote
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions.  You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.

You are not responsible for enforcing compliance by third parties to
this License.

The GPL is pretty stringent (beyond just this quote) about not adding restrictions beyond what is already in the license.  Whilst you are allowed to charge money for GPL software, once you have it on your hands it should have no further restrictions, etc etc.  Having a runtime restriction sounds suspiciously like a restriction.

I'm not in a position to report it to Microchip because I don't have a copy of the software to confirm that this is all the case first hand.  Someone who does: please consider reporting it to Microchip, it might be a mistake on they own up to and fix.

Quote
I wonder if getting FSF involved in this would ever work? It is their work that MC decided to put a license check on, especially for AVR-GCC component in XC8 v2.00 which is literally unmodified, stock AVR-GCC and AVR-libc.

I'd recommend taking things slowly.  Inform microchip first, see if they respond.  Only escalate to informing other groups if they continue to violate.  After all, we ourselves can be mistaken.
« Last Edit: September 08, 2018, 01:37:12 pm by Whales »
 

Offline Whales

  • Super Contributor
  • ***
  • Posts: 1899
  • Country: au
    • Halestrom
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #22 on: September 08, 2018, 01:34:49 pm »
Sidenote: why do I care about a license violation with software I don't use?

If the company doesn't care about licensing then I don't want them anywhere near any work I do, because they probably don't care about mine either.

I've been in these shoes before regarding a project that wanted to re-license.  They were trying to bend the rules a bit (many historical authors could not be contacted/were gone), I thought that it's unwise to expect other people to respect your license if you don't even respect your own.
« Last Edit: September 08, 2018, 01:37:38 pm by Whales »
 
The following users thanked this post: newbrain

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #23 on: September 08, 2018, 02:26:20 pm »
Microchip are hardly the only ones to sell license-protected builds of GCC (eg. Montavista, IIRC Mentor Graphics/CodeSourcery too). The GCC developers seem fine with this, as long as the source code is freely available.

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #24 on: September 08, 2018, 07:05:11 pm »
Microchip are hardly the only ones to sell license-protected builds of GCC (eg. Montavista, IIRC Mentor Graphics/CodeSourcery too). The GCC developers seem fine with this, as long as the source code is freely available.
Will someone set up a build server that automatically builds Microchip's GCC forks with license checks patched out? That should be fully legal (as indicated by GPL) and should result in drop-in replacements for Microchip's distribution.

Also this does mean it is full legal to apply binary patches to the Microchip GCC forks to remove license checks.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #25 on: September 08, 2018, 07:28:33 pm »
Now I'm getting confused!  If I stay away from Atmel Studio and MPLAB and use arv-libc and the current WinAVR or the Linux equivalent toolchain, can I compile unlimited code or not?  I don't need nor want the vendor tools when there are 'free' versions in the wild.

Other than Arduino, I haven't used an Atmel chip in at least 10 years but I had always though highly of the ATmega128 and I have written a bunch of code for it.  I might like to do so again some day and I would have a tendency to want to use the Linux tools along with avrdude.

Are there chips on the market for which the latest gcc is incapable of generating code?


 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #26 on: September 09, 2018, 04:03:02 am »
Are there chips on the market for which the latest gcc is incapable of generating code?
I have samples of ATmega4809 and ATtiny1617, some new 8-bit AVR, to test this with. AFAIK the entire SMART ARM line and most chip series released before Microchip acquisition has full GCC support.
 

Online hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #27 on: September 09, 2018, 06:33:44 am »
Microchip are hardly the only ones to sell license-protected builds of GCC (eg. Montavista, IIRC Mentor Graphics/CodeSourcery too). The GCC developers seem fine with this, as long as the source code is freely available.
Will someone set up a build server that automatically builds Microchip's GCC forks with license checks patched out? That should be fully legal (as indicated by GPL) and should result in drop-in replacements for Microchip's distribution.

Also this does mean it is full legal to apply binary patches to the Microchip GCC forks to remove license checks.
I wouldn't go as far as saying "full". These terms may apply to the GCC binary from XC compiler, but what about MPLAB X? I haven't checked, but it may have a constraint saying you can't use 3rd party or modified compilers with their software. After all, MPLAB integrates the compiler package, debugger and device support dialogs all together to make a fully functional toolchain.

Nonetheless, I'm still amazed why they want to hard-split their own customer base like that. Maybe (also guessing/speculating here) Microchip is having lots of relatively small customers in the thousand quantity region. The existance of MicrochipDirect and low-quantity production programming support would suggest that.
There could be too little margin in todays chips, that they want to make money twice of their customers by also selling them a "premium" compiler. If you have spend 1k$ on a compiler and only ever sell a few thousand 1$ parts, then that's probably more earned by the compiler than the actual silicon.
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #28 on: September 09, 2018, 09:46:35 am »
don't forget that they keep increasing the price of older chips in order to
- move people to newer and better chips
- squeeze more money from people who can't or don't want to use pin-to-pin compatible. (if you want you can still get the ancient chips in mask rom or OTP memory, new stock)

In the end the code generated by XC8 is FINE for a free compiler. From time to time i run comparisons between free and pro code and the difference in code size is minimal, like speeding up the startup routine or using more the indirect registers. you just have to know how to write good code for your platform, the architecture is what it is so you can't optimize it that much.
the GCC license check can be bypassed easily as we saw in the past threads, if you want to compile GCC the source code is there in the download archives as it has always been (altough the AVR part of XC8 is not there yet..)
but -O1 is usually good enough (we ran some tests on generated code here in this forum some months ago, little difference for higher optimizations, the listing file was more and more confusing to read as the optimizer put pieces of code together and rearranged instructions in order to gain some more speed or space)
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #29 on: September 11, 2018, 11:44:15 pm »
Quote
If I stay away from Atmel Studio and MPLAB and use arv-libc and the current WinAVR
There is no "current" WinAVR.  The last AVR build was in 2010, and has avr-gcc v4.3.3.The replacement since then has been primarily the "toolchain" CLI tools downloadable from ... Atmel.(Currently gcc 5.4.0.  The most recent avr-gcc "from source" is v8.2, I think)


Quote
The XC8-AVR contains a copy of AVR-GCC with Microchip XC8 license check
Yep.   Really a depressing step...

WWHackintosh<9983> /Applications/microchip/xc8/v2.00/avr/bin/avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.2_42) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

WWHackintosh<9984> /Applications/microchip/xc8/v2.00/avr/bin/avr-gcc -Os /tmp/str.c
/tmp/str.c:1:0: warning: Compiler option (Optimize for size) ignored because the free XC8 compiler does not support this feature.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #30 on: September 12, 2018, 01:04:02 am »
Quote
Really a depressing step...
I guess they figure if they can get a grand from the xc16/32 'pro' users, why not the 'pro' avr (and sam) users also.

Although they don't have an easy 'backdoor' option like xc16/32 (that I know of- no source released), the binaries can be changed easily enough even without the source as they use the same method as xc16/32 to check the license. Change a -1 to a 2 in the binaries .data section (3 binaries) and you are good to go.

The arm compiler they have in xc32 also restricts optimizations, so they are going all in with this idea.

The only positive is they currently provide the source code to xc16/32 from their web site. I can imagine the next step will be to require anyone wanting the source to send in their $100 to request a copy.

I guess we all can get into the compiler business.  Get the source code, change one line in the source code (for those that will request the source code), modify a few bytes in 3 binaries (no need to compile), sell the 3 binaries for $x, offer to provide the source for a $100 fee. Repeat for every version that comes out.

Anyone want to buy some binaries from me?
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #31 on: September 12, 2018, 08:22:05 am »
Quote
Really a depressing step...
I guess they figure if they can get a grand from the xc16/32 'pro' users, why not the 'pro' avr (and sam) users also.

Although they don't have an easy 'backdoor' option like xc16/32 (that I know of- no source released), the binaries can be changed easily enough even without the source as they use the same method as xc16/32 to check the license. Change a -1 to a 2 in the binaries .data section (3 binaries) and you are good to go.

The arm compiler they have in xc32 also restricts optimizations, so they are going all in with this idea.

The only positive is they currently provide the source code to xc16/32 from their web site. I can imagine the next step will be to require anyone wanting the source to send in their $100 to request a copy.

I guess we all can get into the compiler business.  Get the source code, change one line in the source code (for those that will request the source code), modify a few bytes in 3 binaries (no need to compile), sell the 3 binaries for $x, offer to provide the source for a $100 fee. Repeat for every version that comes out.

Anyone want to buy some binaries from me?
Maybe we really should start a build server and releasing our own version of Microchip GCC’s with license checks patched out. We need to have a build server that can produce up-to-date binaries in time for every upstream release.

* XC8-AVR: just plain AVR-GCC from upstream.
* XC16: It is GCC after all, with a custom backend. We can take MCHP’s source code, strip out the license check, and rebuild as-is. When rebuilding we can even turn on C++ support.
* XC32: The XC32-MIPS part is based on GCC and AFAIK it generates worse code than stock MIPS32 GCC, and the ARM part is stock GCC (just like XC8-AVR) so the build server would build straight upstream MIPS32-GCC as XC32-MIPS replacement and make use of the ARM’s official release for XC32-ARM, and build stock upstream GCC-AVR32
« Last Edit: September 12, 2018, 08:25:47 am by technix »
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #32 on: September 12, 2018, 11:25:56 am »
Maybe we really should start a build server and releasing our own version of Microchip GCC’s with license checks patched out.
The sources build with the license check disabled by default.

Quote
The XC32-MIPS part is based on GCC and AFAIK it generates worse code than stock MIPS32 GCC, and the ARM part is stock GCC (just like XC8-AVR) so the build server would build straight upstream MIPS32-GCC as XC32-MIPS replacement and make use of the ARM’s official release for XC32-ARM, and build stock upstream GCC-AVR32
Microchip have added a lot of functionality to their GCC and binutils forks that are not upstreamed. A vanilla mipsel-gcc will not work as a drop-in XC32 replacement. Their GCC compilers also used to be based on CodeSourcery's/Mentor's codebase, but I don't know if this is still the case (upstream MIPS support was severely behind CS' releases for a very long time). It remains to be seen whether Microchip will add their modifications to their AVR and ARM compilers as well.

Note that eg. Ubuntu's package repositories have an avr-gcc that's built straight from Atmel's source releases, and MacPorts have a very up to date vanilla avr-gcc 8.2.
 
The following users thanked this post: technix, JPortici

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #33 on: September 12, 2018, 11:55:18 am »
Maybe we really should start a build server and releasing our own version of Microchip GCC’s with license checks patched out.
The sources build with the license check disabled by default.
This might actually be a GPL violation if code change is required to bring back that license check - the distributed source code does not match the binaries if the don't behave the same.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #34 on: September 12, 2018, 12:13:56 pm »
This might actually be a GPL violation if code change is required to bring back that license check - the distributed source code does not match the binaries if the don't behave the same.
Don't be daft. By that logic, any program that used #ifdefs would violate the GPL.

Offline Eturtle

  • Newbie
  • Posts: 6
  • Country: de
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #35 on: January 23, 2019, 07:40:22 pm »
tested on arch-linux. enjoy O3,Os,lto with unmodified xclm
Code: [Select]
cd /opt/microchip/xc8/v2.05/avr/libexec/gcc/avr/5.4.0/

printf '\x90\x90\xc7\x05\x30\xed\xf8\x08\x02' | dd of=cc1 bs=1 seek=8175160 count=9 conv=notrunc
printf '\x90\x90\xc7\x05\xd0\xad\x0c\x09\x02' | dd of=cc1plus bs=1 seek=9241176 count=9 conv=notrunc
printf '\x90\x90\xc7\x05\x90\xcb\xec\x08\x02' | dd of=lto1 bs=1 seek=7578772 count=9 conv=notrunc
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #36 on: January 24, 2019, 01:38:33 am »
100 ways to mod, here is a single bit mod (if I could write to one single bit in a file, anyway).
83 f1 01   xor    $0x1,%ecx -> $0x1 -> $0x0 -> free license=0, 0 xor 0 = 0, if 0 then clear nullify optimization vars previously set
I guess changing a je/jne (74<->75) also qualifies as a single bit mod, but is not as much fun and I can't use /dev/zero in that case.

Quote
cd /opt/microchip/xc8/v2.05/avr/libexec/gcc/avr/5.4.0/

mod(){ dd if=/dev/zero of=$1 bs=1 count=1 seek=$2 conv=notrunc; }
mod cc1 $((0x7cbe74)); mod cc1plus $((0x8d0294)); mod lto1 $((0x73a4d0))
 

Offline blacksheeplogic

  • Frequent Contributor
  • **
  • Posts: 532
  • Country: nz
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #37 on: January 24, 2019, 04:01:56 am »
WWHackintosh<9984> /Applications/microchip/xc8/v2.00/avr/bin/avr-gcc -Os /tmp/str.c
/tmp/str.c:1:0: warning: Compiler option (Optimize for size) ignored because the free XC8 compiler does not support this feature.
[/tt]

I worked in a team optimizing both the C & Fortran compilers for a very large company. We gave our optimizations to GCC only after out compiler had been out in the field for a considerable period of time (it varied).

It's expensive development and we invested millions into the compilers and processors. It has to be paid somehow and competitive advantage was one of the ways we justified this development.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #38 on: January 24, 2019, 07:16:13 am »
BTW, the updated version of XC8 apparently supports -Os and -O2 even in the "free" version.I'm not sure about -flto...

Quote
We gave our optimizations to GCC only after out compiler had been out in the field
In this case, Microchip was/is turning OFF the availability of common optimization options implemented by the community and/or other vendors (perhaps even you) that have been available for years (are still available, if you download the "avr-gcc" binaries, or compile from source.)  It's just ... sleazy.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #39 on: January 24, 2019, 07:43:34 am »
Microchip are hardly the only ones to sell license-protected builds of GCC (eg. Montavista, IIRC Mentor Graphics/CodeSourcery too). The GCC developers seem fine with this, as long as the source code is freely available.
Will someone set up a build server that automatically builds Microchip's GCC forks with license checks patched out? That should be fully legal (as indicated by GPL) and should result in drop-in replacements for Microchip's distribution.

Also this does mean it is full legal to apply binary patches to the Microchip GCC forks to remove license checks.
I wouldn't go as far as saying "full". These terms may apply to the GCC binary from XC compiler, but what about MPLAB X? I haven't checked, but it may have a constraint saying you can't use 3rd party or modified compilers with their software. After all, MPLAB integrates the compiler package, debugger and device support dialogs all together to make a fully functional toolchain.

Nonetheless, I'm still amazed why they want to hard-split their own customer base like that. Maybe (also guessing/speculating here) Microchip is having lots of relatively small customers in the thousand quantity region. The existance of MicrochipDirect and low-quantity production programming support would suggest that.
There could be too little margin in todays chips, that they want to make money twice of their customers by also selling them a "premium" compiler. If you have spend 1k$ on a compiler and only ever sell a few thousand 1$ parts, then that's probably more earned by the compiler than the actual silicon.
MPLAB X is also GPL software, being based on NetBeans 8 or lower.

Microchip is slapping their license check code into GPL code left and right here, and disabling features based on that. MPLAB X is based on NetBeans, XC8-AVR, XC16 and XC32 are all based on GCC. The only part they have license check and being illegal to patch is XC8-PIC which is based on either proprietary code or LLVM/clang.

I think I am going to try set up and release manual builds of those tools with license checks patched out. My avr-gcc is not going to be whatever fork they are using, instead it is based on FSF mainline releases. XC16 and XC32 are patched Microchip code.
« Last Edit: January 24, 2019, 07:47:36 am by technix »
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #40 on: January 24, 2019, 01:34:22 pm »
Quote
TW, the updated version of XC8 apparently supports -Os and -O2 even in the "free" version
Up to -O2, does not include -Os (both xc8-pic, xc8-avr).

Quote
I think I am going to try set up and release manual builds of those tools with license checks patched out
In the case of xc16/xc32, its not necessary as you need a 2 line text file to get all optimizations. For xc8-avr, I just showed 2 lines of script to take care of it. Why do you want to go through all that trouble to compile these into something that will be different than what everyone else is using? I'm not saying you can't do it, but am asking why would you want to?

Quote
Microchip is slapping their license check code into GPL
The actual license check code is a separate file. The calling of that external program is done from the gpl code, and the gpl code source is available to download. I didn't just magically figure out that changing the literal of an xor instruction results in no optimization nullification, I had help in the form of source code (still had to hunt where that source code ended up in the binary).

Quote
MPLAB X is also GPL software
http://wiki.netbeans.org/FaqCommercialApp
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #41 on: January 24, 2019, 02:41:14 pm »
It's just ... sleazy.

according to a guy formerly in the XC8 team, it took a long time for them to convince management to give away -O2 but they finally succeded. I have a feeling that the atmel deal has some influence in the decision. I hope this gets on to XC16 and XC32.. and in the end free full optimizations for all.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #42 on: January 24, 2019, 05:19:38 pm »
Quote
I think I am going to try set up and release manual builds of those tools with license checks patched out
In the case of xc16/xc32, its not necessary as you need a 2 line text file to get all optimizations. For xc8-avr, I just showed 2 lines of script to take care of it. Why do you want to go through all that trouble to compile these into something that will be different than what everyone else is using? I'm not saying you can't do it, but am asking why would you want to?
For the peace of heart, that my compiler carrying the GCC name is vanilla GPL code, not a package infested with proprietary code.

Quote
Microchip is slapping their license check code into GPL
The actual license check code is a separate file. The calling of that external program is done from the gpl code, and the gpl code source is available to download. I didn't just magically figure out that changing the literal of an xor instruction results in no optimization nullification, I had help in the form of source code (still had to hunt where that source code ended up in the binary).
It appeared to me that recent versions of GCC has an internal integrity check that makes it nag when binary edited it. Patching out that code results in a binary that does not nag.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #43 on: January 24, 2019, 06:09:45 pm »
Quote
It appeared to me that recent versions of GCC has an internal integrity check that makes it nag when binary edited it. Patching out that code results in a binary that does not nag
Yes, they check if their xclm program is the 'real' one, but who cares. No one is touching that piece of software and it is free to do what it wants, and it doesn't matter. It will just tell the compiler executable (which calls it) that we have a free license. Not important. In the case of xc8-avr, I just changed a bit in the gpl binaries so optimization nullification is 'undone' as if we have something greater than a free license.

Unless you have a lot of free time, you are not going to roll your own xc16/32 version of gcc easily unless you stick to the sources they have provided. At that point... there is no point as you are then not gaining anything. In the case of avr/arm, there probably is no point either as you can simply tell mplabx to use another compiler- point it to the latest version of gcc-avr or gcc-arm in some folder on your pc, it will use it.

The source code is available from MCHP, and you are free to look at it, study it, and understand what its doing. You are also free to compile it if you wish.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #44 on: January 24, 2019, 07:07:30 pm »
WWHackintosh<9984> /Applications/microchip/xc8/v2.00/avr/bin/avr-gcc -Os /tmp/str.c
/tmp/str.c:1:0: warning: Compiler option (Optimize for size) ignored because the free XC8 compiler does not support this feature.
[/tt]

I worked in a team optimizing both the C & Fortran compilers for a very large company. We gave our optimizations to GCC only after out compiler had been out in the field for a considerable period of time (it varied).

It's expensive development and we invested millions into the compilers and processors. It has to be paid somehow and competitive advantage was one of the ways we justified this development.

Nobody disputes that it is expensive. But that is not an excuse to violate/ignore the license of the software that one is (or rather Microchip)  distributing and which saved even more R&D money (writing a semi-decent compiler for any language/architecture is expensive). I am sure Microchip's lawyers would not be happy neither if someone took their paid software and started distributing it or decompiling it or doing whatever else that their license forbids.

If a company wants to keep stuff closed and locked down then they shouldn't use GPLed software as a base of the derivative work, it is that simple. Either use something else that is less restrictively licensed (e.g. LLVM) or write your own code.

In Microchip's case this has been going on for at least 10 years:
https://www.embeddedrelated.com/showthread/comp.arch.embedded/91196-1.php

I suspect that they provide the uncrippled (including optimization, etc.) source code for download, just most people couldn't be bothered to build it. In that case they are likely to escape any wrath of the FSF lawyers because they have fulfilled their obligations as both the source is available and there is no extra restriction attached (ok, you have to recompile the program but that's hardly an obstacle. Certainly not any kind of DRM). OTOH, if they ship only a source to a crippled version without the optimization and other "secret sauce", then they would be in violation of the license.
 
The following users thanked this post: newbrain

Offline Teemo

  • Regular Contributor
  • *
  • Posts: 58
  • Country: ee
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #45 on: February 03, 2019, 01:06:18 am »
Regarding the XC8 ver 2.05
I just installed and tried it out. Not with AVR but with PIC.
Seems Microchip is sinking with that too.
I had a conversation about the so called "bloat" in the free versions some time ago. Accidentally posted a question and suddenly it became clear that I unknowingly stumbled up on to the bloat issue. Link here:https://www.microchip.com/forums/m1067094-p2.aspx

So now in the new version I discover that the mentioned bloat actually still there, but they have edited the dissassembly listing generator so that it do not show the bloated parts correctly.  Bloat is still there but the addresses where it is are in some other place in the file! Coincidental bug?
Disassembly listing jumps right from the address 001E to 0022. And guess what is missing form between? (it is still in some other place in the file)

So  they are sinking very well. Not only with making XC8 for AVR but with making XC8 for PIC as well. Better stay clear.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #46 on: February 03, 2019, 04:20:05 am »
If one is scared of spiders, every little thing that moves looks like a spider.

Quote
the so called "bloat" in the free versions
There is no bloat issue. The compiler starts out producing code, then refines it to remove things not needed, or to speed up or reduces size or whatever else it wants to do to optimize. The free version just does not do all the steps. They just added the -O2 option to the free version, so they are giving away more 'code refining' steps. For the average user, the lack of -O3 or -Os in xc8-pic is nothing to get excited about.

The listings you show only proves that they cannot produce any disassembly listing in a continuous order. They are not trying to hide anything, or intentionally confuse you. You can debug via the simulator (or real), debugging->disassembly (not disassembly listing file), and probably get a look at the actual instructions of interest in order (for whatever function you are in).

There are no spiders here.
 
The following users thanked this post: mikerj, JPortici, cobusve

Offline Teemo

  • Regular Contributor
  • *
  • Posts: 58
  • Country: ee
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #47 on: February 04, 2019, 04:02:45 pm »
I was looking through Microchip's website and I realized that XC8 PRO ( the not-free and expensive version of Microchip's 8 bit compiler) is a thing for AVR with the new AVR support in MPLAB X. I find it hilarious because no one is going to buy XC8 pro for something that already has pretty good compilers. However, it got me thinking. How does the XC8 compiler compare in terms of optimizations? Does microchip plan on dropping support for the free AVR compilers with Atmel Studio and not including them in MPLAB X in hopes that people are forced to buy their stupid expensive compilers if they want better optimizations? When I first heard that AVR support was coming to MPLAB X was great since it meant a proper IDE for AVR in Linux but now it's a little terrifying.

/Begin rant

Let's face it, Microchip should release their XC8 compilers and stick to the hardware business. I'm sure they have made enough money back from their purchase of the HI-TECH C compilers already. I also don't think that "go mess with assembly if you want optimizations" is a good answer either since you would expect a hardware manufacturer to make their hardware as accessable to everyone as possible. Companies where a few thousand dollars for a compiler is a formality are exempt from this rant, although they kind of perpetuate the problem by forking over the cash.

Don't get me wrong, I've only dealt with PICs so I am by no means an AVR fan boy. It's just kind of frustrating to see this and to think that Microchip might possibly be trying to force AVR into this, too.

/End rant

Sorry for any errors, typed this out with my phone. IX
Ok lets face the current situation: Microchip bought out their former best friend and co-operator HiTech. And by doing this entered into the competition with all the other independent compiler manufacturers for the PIC-s.
So now they lost a friend via the buying. (Seems surrently trying to leach back off the buying price, from the compiler business section.)
And also lost other cooperators, the independent compiler developers, by entering into competition with them. 
Who would want to compete with the chip manufacturer itself with developing the compiler and IDE, in the situation when there is always the threat that chip manufacturer can realease its compilers for free at the any moment suitable?

Also the huge deal of buying the Atmel. Probably still digesting the big cost of that. And the same thing: entering to the competition with the compiler development, thus trying to kill off independent compilers.

So no wonder the situation is terrifying. But lets look at the bright side -- for a moment it looked like the Microchip and Atmel would get too much monopoly in the MCU market certain sectors, now it is been going more balanced.
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #48 on: February 06, 2019, 07:55:12 am »
I wonder if this is doable:

Code: [Select]
char padding[64] = {};
int main(void) { return 6; }

Then use a mining rig to brute force a hash collision in padding array? The whole cryptocurrency proof of work is based on hash collision anyway.

The binary can be constructed in a way that the padding bytes coextends with one hash block and whatever comes after the block is less than one hash block long - better if the padding block us the last block. This will allow the brute force effort make use of partial resumption of hashes and reduce the block count to less than three, allowing some speed up of the collision process.
 

Offline Jan Audio

  • Frequent Contributor
  • **
  • Posts: 820
  • Country: nl
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #49 on: February 07, 2019, 05:00:26 pm »
Their processors are crap anyway, so no loss.

The other companys has no DIP packages, amateur that i am.
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 2281
  • Country: gb
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #50 on: September 24, 2019, 12:23:13 pm »
For Windows-
C:\Program Files (x86)\Microchip\xc8\v2.00\avr\libexec\gcc\avr\5.4.0\cc1.exe  - file offset 0xBF5890 - change FFFFFFFFFFFFFFFF to 0200000000000000

Address has shifted a little for AVR "PRO" mode in XC8 v2.10 (MS Windows):
C:\Program Files (x86)\Microchip\xc8\v2.10\avr\libexec\gcc\avr\5.4.0\cc1.exe  - file offset 0xC22690 - change FFFFFFFFFFFFFFFF to 0200000000000000
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #51 on: September 24, 2019, 04:27:23 pm »
For Windows-
C:\Program Files (x86)\Microchip\xc8\v2.00\avr\libexec\gcc\avr\5.4.0\cc1.exe  - file offset 0xBF5890 - change FFFFFFFFFFFFFFFF to 0200000000000000

Address has shifted a little for AVR "PRO" mode in XC8 v2.10 (MS Windows):
C:\Program Files (x86)\Microchip\xc8\v2.10\avr\libexec\gcc\avr\5.4.0\cc1.exe  - file offset 0xC22690 - change FFFFFFFFFFFFFFFF to 0200000000000000
Can I just compile upstream avr-gcc and avr-libc, and use that as a drop-in? Also how good is Microchip's optimizer for GCC 5.4 than that in mainline GCC 8.2?
 
The following users thanked this post: bmjjr

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #52 on: September 24, 2019, 11:42:18 pm »
Quote
Can I just compile upstream avr-gcc and avr-libc, and use that as a drop-in?
People have done it. ( https://www.avrfreaks.net/forum/avr-gcc-91-avr-libc-xmega3-device-support )  IMO, it's risky - the gcc developers don't pay much attention to AVR, and they tend to break things.  One of the reasons that AS7 and XC8 are behind is because of wanting to stay with "known working" code.
avr-libc is thornier.  BSD rather than GPL, so Microchip can in theory develop a divergent version of avr-libc with undocumented changes :-(
 

Online magic

  • Super Contributor
  • ***
  • Posts: 6733
  • Country: pl
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #53 on: September 25, 2019, 07:10:40 am »
I noticed that Atmel/Microchip switched from preprocessor macros to structures and enums in their official C headers for the "xmega3" chips.
Is avr-libc doing the same, are they source-level compatible?

Also, does anyone know why they added suffixes like _gc to the names of enum values? Any official explanation what those things mean? :-//

edit
Nevermind, found it. It's another thing carried over from the Xmega line, documented in AVR1000. The 3rd party avr-libc appears to follow this convention for classic Xmegas so they surely will for the new chips too. If they ever wake up and release an update, that is :)
« Last Edit: September 25, 2019, 08:44:06 am by magic »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Has anyone tried the XC8 PRO compiler with AVRs?
« Reply #54 on: September 25, 2019, 10:23:16 am »
Quote
noticed that Atmel/Microchip switched from preprocessor macros to structures and enums in their official C headers for the "xmega3" chips.
Is avr-libc doing the same, are they source-level compatible?
Yes.  This started with the ARM and XMega chips (CMSIS compatible, more or less.)  Long overdue, IMO.  Having 4 sets of individual registers for the 4 UARTs on an ATmega1280 was silly.
Quote
Also, does anyone know why they added suffixes like _gc to the names of enum values?
_bm: bitmask, for single bits.  _bp: bit position for single bits_gm: group(?) mask, for multibit fields.  _gp: group position.  _gc: group(?) code(?) individual values of multibit field


Quote
documented in AVR1000.
Oh cool!  You found documentation!  ('c' is apparently "configuration", not code.)

Quote
The 3rd party avr-libc ...  surely will for the new chips too. If they ever wake up and release an update, that is
As far as the #include files and compiler specs are concerned, the OSSW compilers can use the files included in the "packs" that microchip distributes.  (supposedly, the chip .h files are generated automatically from some common .xml files that come out of the chip design.  Despite the large number of fixes in avr-libc that say "fixed a particular definition in a particular chip .h file."  Hmmph.)
 

Offline sunjob

  • Newbie
  • Posts: 1
  • Country: ru
avr-gcc vs хс8-avr
« Reply #55 on: January 16, 2021, 01:40:22 am »
this my cut from text's and project's, some tests, avr-gcc vs xc8-avr

Code: (cpp) [Select]
///////////////////////////////////////////
optimisation / size *.hex-file
///////////////////////////////////////////
gcc1 - avr-gcc-3.6.2 custom Makefile
gcc2 - avr-gcc-3.6.2 build on mplabx
xc8  - xc8-2.10      build on mplabx
///////////////////////////////////////////
opt  |  gcc1   |  gcc2   | xc8
///////////////////////////////////////////
s    |  5,496  |  5,696  | 6,357
g    |  5,508  |         |
fast |  5,504  |         |
0    |  5,966  |  8,433  | 9,188
1    |  5,508  |  5,721  | 6,386
2    |  5,500  |  5,700  | 6,361
3    |  5,504  |  5,717  | 6,365
///////////////////////////////////////////

and

Code: (cpp) [Select]
///////////////////////////////////////////
avr-gcc toolchain
- avr_gcc      4.9.2
- avr_binutils 2.25
- avr_gdb      7.8.1
- avr_libc     1.8.1
////////////////////////////////////////////////
gcc  - avr-gcc  build on mplabx
xc8  - xc8-2.20 build on mplabx
////////////////////////////////////////////////
opt  |  gcc    |  xc8    |
////////////////////////////////////////////////
0    |  8,024  |  8,971  |
1    |  5,402  |  6,169  |
2    |  5,381  |  6,144  |
3    |  5,385  |  6,148  |
s    |  5,377  |  6,140  |
////////////////////////////////////////////////

and

Code: (cpp) [Select]
////////////////////////////////////////////////
optimisation -S2
////////////////////////////////////////////////
gcc  - avr-gcc  build on mplabx
xc8  - xc8-2.20 build on mplabx
////////////////////////////////////////////////
    avr-gcc   | xc8 2.20 |
////////////////////////////////////////////////
3.6.2 - 5,496 |   6,144  |
7.3.0 - 5,361 |          |
9.2.0 - 5,336 |          |
////////////////////////////////////////////////
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf