-
Has anyone tried the XC8 PRO compiler with AVRs?
Posted by
IonizedGears
on 22 Jul, 2018 23:12
-
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
-
#1 Reply
Posted by
cv007
on 23 Jul, 2018 04:38
-
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
-
#2 Reply
Posted by
HB9EVI
on 23 Jul, 2018 06:47
-
? 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.
-
#3 Reply
Posted by
HB9EVI
on 23 Jul, 2018 07:50
-
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
-
#4 Reply
Posted by
cv007
on 23 Jul, 2018 13:40
-
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.
-
-
? 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.
-
#6 Reply
Posted by
HB9EVI
on 23 Jul, 2018 17:00
-
before Microchip bought Atmel, the AVR world was perfectly fine without MPLAB
-
-
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.
-
-
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.
-
#9 Reply
Posted by
JPortici
on 23 Jul, 2018 19:01
-
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.
-
#10 Reply
Posted by
cv007
on 23 Jul, 2018 19:33
-
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.
-
#11 Reply
Posted by
HB9EVI
on 23 Jul, 2018 20:27
-
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
-
#12 Reply
Posted by
Eturtle
on 06 Sep, 2018 20:27
-
maybe lets skip the call to avr_get_license at all
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
-
#13 Reply
Posted by
bson
on 07 Sep, 2018 03:11
-
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.
-
#14 Reply
Posted by
cv007
on 07 Sep, 2018 09:13
-
maybe lets skip the call to avr_get_license at all
Let a Windows user try those commands
-
#15 Reply
Posted by
technix
on 08 Sep, 2018 04:27
-
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.
-
-
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,
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
-
#17 Reply
Posted by
Whales
on 08 Sep, 2018 05:41
-
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 :
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.
-
#18 Reply
Posted by
technix
on 08 Sep, 2018 06:28
-
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 :
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.
-
-
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".
-
#20 Reply
Posted by
technix
on 08 Sep, 2018 10:59
-
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.
-
#21 Reply
Posted by
Whales
on 08 Sep, 2018 13:27
-
Eek.
I'll bolden a bit of what I quoted before:
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.
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.
-
#22 Reply
Posted by
Whales
on 08 Sep, 2018 13:34
-
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.
-
#23 Reply
Posted by
andersm
on 08 Sep, 2018 14:26
-
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.
-
#24 Reply
Posted by
technix
on 08 Sep, 2018 19:05
-
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.