Has anyone tried the XC8 PRO compiler with AVRs?  - Page 1
Forum section: electronics / general

author: IonizedGears
author_rank: Regular Contributor
timestamp: July 22, 2018, 11:12:58 pm
content: 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 rantLet'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

author: cv007
author_rank: Frequent Contributor
timestamp: July 23, 2018, 04:38:49 am
content: 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

author: HB9EVI
author_rank: Frequent Contributor
timestamp: July 23, 2018, 06:47:27 am
content: Quote from: IonizedGears on July 22, 2018, 11:12:58 pmthere are proper IDEs on Linux to work with the avr-gcc; there is codeblocks and there is eclipse, what more does somebody need.

author: HB9EVI
author_rank: Frequent Contributor
timestamp: July 23, 2018, 07:50:52 am
content: 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

author: cv007
author_rank: Frequent Contributor
timestamp: July 23, 2018, 01:40:09 pm
content: QuoteAlthough 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.0Copyright (C) 2015 Free Software Foundation, Inc.

author: IonizedGears
author_rank: Regular Contributor
timestamp: July 23, 2018, 04:54:36 pm
content: Quote from: HB9EVI on July 23, 2018, 06:47:27 amThere 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.

author: HB9EVI
author_rank: Frequent Contributor
timestamp: July 23, 2018, 05:00:14 pm
content: before Microchip bought Atmel, the AVR world was perfectly fine without MPLAB

author: IonizedGears
author_rank: Regular Contributor
timestamp: July 23, 2018, 05:23:17 pm
content: Quote from: cv007 on July 23, 2018, 04:38:49 amI'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.

author: IonizedGears
author_rank: Regular Contributor
timestamp: July 23, 2018, 06:42:23 pm
content: Quote from: HB9EVI on July 23, 2018, 05:00:14 pmAtmel 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.

author: JPortici
author_rank: Super Contributor
timestamp: July 23, 2018, 07:01:16 pm
content: i like MPLAB X waaaaaaaaay betteraltough 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.

author: cv007
author_rank: Frequent Contributor
timestamp: July 23, 2018, 07:33:23 pm
content: QuoteFor Windows-C:\Program Files (x86)\Microchip\xc8\v2.00\avr\libexec\gcc\avr\5.4.0\cc1.exe - file offset 0xBF5890 - change FFFFFFFFFFFFFFFF to 0200000000000000Now 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.

author: HB9EVI
author_rank: Frequent Contributor
timestamp: July 23, 2018, 08:27:20 pm
content: 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

author: Eturtle
author_rank: Newbie
timestamp: September 06, 2018, 08:27:30 pm
content: maybe lets skip the call to avr_get_license at allCode:cd /opt/microchip/xc8/v2.00/avr/libexec/gcc/avr/5.4.0printf '\x90\x90\xc7\x05\x10\x62\xf8\x08\x02' | dd of=cc1 bs=1 seek=8170722 count=9 conv=notruncprintf '\x90\x90\xc7\x05\x90\x3b\xec\x08\x02' | dd of=lto1 bs=1 seek=7575626 count=9 conv=notrunc

author: bson
author_rank: Unknown
timestamp: September 07, 2018, 03:11:20 am
content: 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.

author: cv007
author_rank: Frequent Contributor
timestamp: September 07, 2018, 09:13:38 am
content: QuoteLet a Windows user try those commands

author: technix
author_rank: Super Contributor
timestamp: September 08, 2018, 04:27:39 am
content: This is a bit outrageous to me, applying license limitations tostock 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.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: September 08, 2018, 05:09:42 am
content: Quote from: bson on September 07, 2018, 03:11:20 amI 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

author: Whales
author_rank: Super Contributor
timestamp: September 08, 2018, 05:41:04 am
content: Quote from: technix on September 08, 2018, 04:27:39 amWait 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?Fromhttps://www.gnu.org/licenses/gpl-3.0-standalone.html:QuoteI 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.

author: technix
author_rank: Super Contributor
timestamp: September 08, 2018, 06:28:33 am
content: Quote from: Whales on September 08, 2018, 05:41:04 amThe 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.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: September 08, 2018, 09:08:10 am
content: Quote from: technix on September 08, 2018, 04:27:39 amMicrochip 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".

author: technix
author_rank: Super Contributor
timestamp: September 08, 2018, 10:59:59 am
content: Quote from: donotdespisethesnake on September 08, 2018, 09:08:10 amI 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.

author: Whales
author_rank: Super Contributor
timestamp: September 08, 2018, 01:27:29 pm
content: Eek.I'll bolden a bit of what I quoted before:QuoteThe 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.QuoteI'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.

author: Whales
author_rank: Super Contributor
timestamp: September 08, 2018, 01:34:49 pm
content: 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.

author: andersm
author_rank: Super Contributor
timestamp: September 08, 2018, 02:26:20 pm
content: Microchip are hardly the only ones to sell license-protected builds of GCC (eg. Montavista, IIRC Mentor Graphics/CodeSourcery too). The GCC developersseem fine with this, as long as the source code is freely available.

author: technix
author_rank: Super Contributor
timestamp: September 08, 2018, 07:05:11 pm
content: Quote from: andersm on September 08, 2018, 02:26:20 pmWill 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.

author: rstofer
author_rank: Super Contributor
timestamp: September 08, 2018, 07:28:33 pm
content: 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?

author: technix
author_rank: Super Contributor
timestamp: September 09, 2018, 04:03:02 am
content: Quote from: rstofer on September 08, 2018, 07:28:33 pmI 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.

author: hans
author_rank: Super Contributor
timestamp: September 09, 2018, 06:33:44 am
content: Quote from: technix on September 08, 2018, 07:05:11 pmI 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 havinglotsof 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.

author: JPortici
author_rank: Super Contributor
timestamp: September 09, 2018, 09:46:35 am
content: 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)

author: westfw
author_rank: Super Contributor
timestamp: September 11, 2018, 11:44:15 pm
content: QuoteThere 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)QuoteYep. Really a depressing step...WWHackintosh<9983>/Applications/microchip/xc8/v2.00/avr/bin/avr-gcc --versionavr-gcc (AVR_8_bit_GNU_Toolchain_3.6.2_42) 5.4.0Copyright (C) 2015 Free Software Foundation, Inc.This is free software; see the source for copying conditions. There is NOwarranty; 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.

author: cv007
author_rank: Frequent Contributor
timestamp: September 12, 2018, 01:04:02 am
content: QuoteI 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?

author: technix
author_rank: Super Contributor
timestamp: September 12, 2018, 08:22:05 am
content: Quote from: cv007 on September 12, 2018, 01:04:02 amMaybe 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

author: andersm
author_rank: Super Contributor
timestamp: September 12, 2018, 11:25:56 am
content: Quote from: technix on September 12, 2018, 08:22:05 amThe sources build with the license check disabled by default.QuoteMicrochip 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.

author: technix
author_rank: Super Contributor
timestamp: September 12, 2018, 11:55:18 am
content: Quote from: andersm on September 12, 2018, 11:25:56 amThis 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.

author: andersm
author_rank: Super Contributor
timestamp: September 12, 2018, 12:13:56 pm
content: Quote from: technix on September 12, 2018, 11:55:18 amDon't be daft. By that logic, any program that used #ifdefs would violate the GPL.

author: Eturtle
author_rank: Newbie
timestamp: January 23, 2019, 07:40:22 pm
content: tested on arch-linux. enjoy O3,Os,lto with unmodified xclmCode: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=notruncprintf '\x90\x90\xc7\x05\xd0\xad\x0c\x09\x02' | dd of=cc1plus bs=1 seek=9241176 count=9 conv=notruncprintf '\x90\x90\xc7\x05\x90\xcb\xec\x08\x02' | dd of=lto1 bs=1 seek=7578772 count=9 conv=notrunc

author: cv007
author_rank: Frequent Contributor
timestamp: January 24, 2019, 01:38:33 am
content: 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 setI 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

author: blacksheeplogic
author_rank: Frequent Contributor
timestamp: January 24, 2019, 04:01:56 am
content: Quote from: westfw on September 11, 2018, 11:44:15 pmI 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.

author: westfw
author_rank: Super Contributor
timestamp: January 24, 2019, 07:16:13 am
content: BTW, the updated version of XC8 apparently supports -Os and -O2 even in the "free" version.I'm not sure about -flto...QuoteIn 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.

author: technix
author_rank: Super Contributor
timestamp: January 24, 2019, 07:43:34 am
content: Quote from: hans on September 09, 2018, 06:33:44 amMPLAB 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.

author: cv007
author_rank: Frequent Contributor
timestamp: January 24, 2019, 01:34:22 pm
content: QuoteUp to -O2, does not include -Os (both xc8-pic, xc8-avr).QuoteIn 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?QuoteThe 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).Quotehttp://wiki.netbeans.org/FaqCommercialApp

author: JPortici
author_rank: Super Contributor
timestamp: January 24, 2019, 02:41:14 pm
content: Quote from: westfw on January 24, 2019, 07:16:13 amaccording 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.

author: technix
author_rank: Super Contributor
timestamp: January 24, 2019, 05:19:38 pm
content: Quote from: cv007 on January 24, 2019, 01:34:22 pmFor the peace of heart, that my compiler carrying the GCC name is vanilla GPL code, not a package infested with proprietary code.Quote from: cv007 on January 24, 2019, 01:34:22 pmIt 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.

author: cv007
author_rank: Frequent Contributor
timestamp: January 24, 2019, 06:09:45 pm
content: QuoteYes, 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.

author: janoc
author_rank: Super Contributor
timestamp: January 24, 2019, 07:07:30 pm
content: Quote from: blacksheeplogic on January 24, 2019, 04:01:56 amNobody 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.phpI 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.

author: Teemo
author_rank: Regular Contributor
timestamp: February 03, 2019, 01:06:18 am
content: Regarding the XC8 ver 2.05I 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.aspxSo 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.

author: cv007
author_rank: Frequent Contributor
timestamp: February 03, 2019, 04:20:05 am
content: If one is scared of spiders, every little thing that moves looks like a spider.QuoteThere 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.

author: Teemo
author_rank: Regular Contributor
timestamp: February 04, 2019, 04:02:45 pm
content: Quote from: IonizedGears on July 22, 2018, 11:12:58 pmOk 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.

author: technix
author_rank: Super Contributor
timestamp: February 06, 2019, 07:55:12 am
content: I wonder if this is doable:Code:char padding = {};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.

author: Jan Audio
author_rank: Frequent Contributor
timestamp: February 07, 2019, 05:00:26 pm
content: Quote from: bson on September 07, 2018, 03:11:20 amThe other companys has no DIP packages, amateur that i am.

author: voltsandjolts
author_rank: Unknown
timestamp: September 24, 2019, 12:23:13 pm
content: Quote from: cv007 on July 23, 2018, 07:33:23 pmAddress 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

author: technix
author_rank: Super Contributor
timestamp: September 24, 2019, 04:27:23 pm
content: Quote from: voltsandjolts on September 24, 2019, 12:23:13 pmCan 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?

author: westfw
author_rank: Super Contributor
timestamp: September 24, 2019, 11:42:18 pm
content: QuotePeople 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 :-(

author: magic
author_rank: Super Contributor
timestamp: September 25, 2019, 07:10:40 am
content: 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?editNevermind, 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

author: westfw
author_rank: Super Contributor
timestamp: September 25, 2019, 10:23:16 am
content: QuoteYes. 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_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 fieldQuoteOh cool! You found documentation! ('c' is apparently "configuration", not code.)QuoteAs 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.)

author: sunjob
author_rank: Newbie
timestamp: January 16, 2021, 01:40:22 am
content: this my cut from text's and project's, some tests,avr-gccvsxc8-avrCode: (cpp)///////////////////////////////////////////optimisation / size *.hex-file///////////////////////////////////////////gcc1 - avr-gcc-3.6.2 custom Makefilegcc2 - avr-gcc-3.6.2 build on mplabxxc8 - xc8-2.10 build on mplabx///////////////////////////////////////////opt | gcc1 | gcc2 | xc8///////////////////////////////////////////s | 5,496 | 5,696 | 6,357g | 5,508 | |fast | 5,504 | |0 | 5,966 | 8,433 | 9,1881 | 5,508 | 5,721 | 6,3862 | 5,500 | 5,700 | 6,3613 | 5,504 | 5,717 | 6,365///////////////////////////////////////////andCode: (cpp)///////////////////////////////////////////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 mplabxxc8 - 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 |////////////////////////////////////////////////andCode: (cpp)////////////////////////////////////////////////optimisation -S2////////////////////////////////////////////////gcc - avr-gcc build on mplabxxc8 - 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 | |////////////////////////////////////////////////