MPLAB X a PIC inhibitor! Alternatives ?

[cv007]

The source to xclm is available?

No. The source to xclm is not available, but who cares- xclm is not needed. Forget xclm. Not required.

The source for the XC gcc compilers is here-
http://www.microchip.com/development-tools/downloads-archive
there is a file mhcp.c which has the license checking (and also includes the gpl license)- this is the source I was referring to.

There is nothing sinister about modifying gpl programs- that is the whole purpose of the license.


for f in cc1plus cc1 lto1; do a=($(objdump -T $f | grep mchp_pic32_license_valid)); b=($(objdump -h $f | grep " .data ")); offset=$((0X${a[0]}-0x${b[4]}+0x${b[5]})); printf "%0.8x: 0600 0000 0000 0000" $offset | xxd -r - $f; done

[mikeselectricstuff]

Just out of curiosity I downloaded the XC32 source.
Over 103,00 files....

[westfw]

Over 103,00 files

Yeah...  You didn't think gcc was SMALL, did you?   I count over 80000 files for gcc (not including binutils) (dowloaded from fsf)
After all, it has C, and C++, and Fortran, and Ada, and Java and who knows what else...  And generally architecture-specific files for a whole slew of architectures (although, if you want the most recent version for any particular architecture, you'd be ill advised to use the gcc download from a vendor who primarily sells some other architecture...)
XC32 probably adds an include file and a linker script for each separate PIC32 chip.

This is why people are willing to pay microchip for a rather old version instead of piecing together the latest and greatest generic MIPS compiler and assorted libraries.  It doesn't take much $50/h engineer time fussing with build processes and dependency hell before you could have just paid for a full license.  Or put up with the lesser optimization.

the corporates will hate on GPL

In my time, a fair number of people made a good living writing compilers.  Not so much any more.  I have a bit of fear for the next generation, when gcc is likely to be all that's available, and it's maintained by a bunch of amateurs (or competing vendor-acquired hackers...)

[andersm]

After all, it has C, and C++, and Fortran, and Ada, and Java and who knows what else...

Also 30 years of history.

I have a bit of fear for the next generation, when gcc is likely to be all that's available, and it's maintained by a bunch of amateurs (or competing vendor-acquired hackers...)

Like most successful open-source projects, the vast majority of GCC development is done on a professional basis. Clang and LLVM are also still gaining popularity, both because its friendlier license and embeddability, and because the more modern codebase means its easier to work on. However it doesn't support nearly as many architectures as GCC, and likely never will. Also, although people have used it with Cortex-M CPUs, it is currently not meant for bare-metal environments.

[Karel]

In my time, a fair number of people made a good living writing compilers.  Not so much any more.

Wrong, it's (still) done by skilled professionals who make a good living with it.

I have a bit of fear for the next generation, when gcc is likely to be all that's available, and it's maintained by a bunch of amateurs

I have no idea what you are talking about. If GCC is good enough to compile the most used (and most reliable) operating system in the world,
it's definitely good enough for my projects.

[Bruce Abbott]

Wrong, it's (still) done by skilled professionals who make a good living with it.

GCC is being maintained by skilled professionals who make a good living out of it?

If GCC is good enough to compile the most used (and most reliable) operating system in the world,

Android?

[andersm]

GCC is being maintained by skilled professionals who make a good living out of it?

I don't know how much they're getting paid, but even a cursory glance at the maintainer list shows that the majority are paid for their work (many with a personal email address listed are also doing work-for-hire). The "open source must mean amateurs" canard is straight out of Microsoft's playbook ca. 1998 and was never particularly true.

[Karel]

Wrong, it's (still) done by skilled professionals who make a good living with it.

GCC is being maintained by skilled professionals who make a good living out of it?

If GCC is good enough to compile the most used (and most reliable) operating system in the world,

Android?

Linux

[Karel]

I can confirm that the command

Code: [Select]

for f in cc1plus cc1 lto1; do a=($(objdump -T $f | grep mchp_pic32_license_valid)); b=($(objdump -h $f | grep " .data ")); offset=$((0X${a[0]}-0x${b[4]}+0x${b[5]})); printf "%0.8x: 0600 0000 0000 0000" $offset | xxd -r - $f; done
works correctly. No need to replace the xclm executable.

Thanks again 

I assume even Bruce will be happy now 

[cv007]

Its too bad I will probably never use the xc16/32 compilers, but you never know. I have played around with pic32/pic24 before,  and they are kind of neat in some ways. I also have tried quite a few arm chips (cheapest dev boards), and the only one I had any fun with was the LPC1114. The documentation was straight forward, didn't have to have a dozen pdf's open, everything I tried worked. I even created my own simple forth in asm (gas). Debugging was easy and fast also. Give me a LPC1114 with some peripherals similar to a newer pic16f and I would be happy(er).


cp elf-cc1 elf-cc1.bak; a=$(objdump -T elf-cc1.bak | grep mchp_mafrlcsj); a=${a:6:2}${a:4:2}${a:2:2}${a:0:2}; old="8b35${a}85f60f85"; new="8b35${a}85f60f84"; xxd -ps elf-cc1.bak | sed "s:$old:$new:" | xxd -r -p - elf-cc1

[hans]

I think if MCHP wants to get their compiler quality up to par with ARM and AVR, they will need to drop this corporate shenanigans.

What does Microchip's 'corporate shenanigans' have to do with updates to GCC for PICs? The compiler is is open-source (not really, but...) so why can't anyone produce a better version if they want? What is stopping the PIC versions from being as up-to-date as others?

Well it has basically been partially answered by westfw. It takes an advanced skill set to develop compilers forwards, above all GCC is an enormous project.

The other part is by 'selling' a GPL product Microchip creates a conflicting interest. As a community it would be hard work on such a project (i.e. push changes upstream) if the only package from Microchip supplied is a ZIP file. There is a nice thing called version control systems, like GIT, which is useful in tracking changes, resolving merge conflicts and cherry picking the right modifications for merging. Going from GIT (or some other technology Microchip internally uses) > ZIP file > GIT sounds like a nightmare.

Above all; if one would was successful in merging the changes together, what guarantee does one have that Microchip doesn't release a new compiler next week with "significant better ISA level optimizations"? Good luck chasing your own tail again..

I think there are probably only 2 types of people that really can/should care:

- Fanatic hobbyists that like the PIC24 and PIC32 parts and want to program the latest language and static checking/optimization technology. But with the struggles imposed I just described, I think most will choose the path of least resistance (different parts).

- The people working at Microchip, because their job is to supply tools to their customers. This is why I call it 'corporate', because somewhere a decision had been taken that they rather will charge $$$ for a GCC compiler and work on their island instead of helping the GCC project forward like other vendors do (ST, Freescale, ARM, Atmel).

I guess the other 'types' of people just don't care, I understand :-) If code runs, it runs. Not fast enough, mangle the code manually until it does, if not resort to inline assembly, or give up and buy a faster chip.

But at some day (e.g. 5-10 years from now), you may find that some middleware library is available only in C++ (think CAN protocols), and need to port this onto an existing board with dsPIC/PIC24. Good luck defending the artificial tool limitations at that moment in time.

(As a side note; I still really like the PIC24 & PIC32 parts.. The PPS on PIC24 is awesome, the peripherals are amazingly simple and intuitive to use.. nice hardware pros, it's just a pity that software tooling is not as good as it can be)

[andersm]

As a community it would be hard work on such a project (i.e. push changes upstream) if the only package from Microchip supplied is a ZIP file.

As a GNU project, GCC requires copyright assignment from all contributors, so upstreaming is not even an option.

The chipKIT project maintains a PIC32 compiler that is more or less the redistributable bits of XC32.

[Bruce Abbott]

The "open source must mean amateurs" canard is straight out of Microsoft's playbook ca. 1998 and was never particularly true.

Nobody said that. My question was, is GCC being maintained by skilled professionals who make a good living out of it?

I don't know how much they're getting paid, but even a cursory glance at the maintainer list shows that the majority are paid for their work

That's a lot of people. Who pays them for working on GCC?

[andersm]

That's a lot of people. Who pays them for working on GCC?

Look at the email addresses. Mentor Graphics (CodeSourcery), RedHat, SUSE, Intel, ARM, AMD, IBM etc. are all major contributors. Note that the list is of maintainers, not all contributors, nor all companies that have sponsored work on the compiler.

Edit: Also absent are the list of non-mainlined ports, like Microchip's.

[ruffy91]

https://gcc.gnu.org/onlinedocs/gcc/Contributors.html

Most of them are paid full-time to work on gcc by their companies.
I think at least 3 people there are from Intel, but they also work on the linux kernel.
You will also find people paid by AMD, ARM and every other processor or operating system vendor.
The second big part should be universities.

[technix]

https://gcc.gnu.org/onlinedocs/gcc/Contributors.html

Most of them are paid full-time to work on gcc by their companies.
I think at least 3 people there are from Intel, but they also work on the linux kernel.
You will also find people paid by AMD, ARM and every other processor or operating system vendor.
The second big part should be universities.

From what I see in various FOSS projects (mostly GNUstep and LLVM,) the main driving force is corporate and academia. Both are highly professional people well paid to do this. Corporate contributor submits code that works best for their commercial purposes like most processor support and some optimize passes. while academia maintains the core functionality and project neutrality like a good portion of language support and moving optimize passes around.

[@rt]

You don’t need MPLABX to write for dsPic.
I think optimisation is the only reason I’m using it, but I have the same dsPic33F project on two operating systems,
and one is a ten or so year old MPLAB 8.36, which is much older than yours.

[fourtytwo42]

You don’t need MPLABX to write for dsPic.
I think optimisation is the only reason I’m using it, but I have the same dsPic33F project on two operating systems,
and one is a ten or so year old MPLAB 8.36, which is much older than yours.

You are correct if you chose your device carefully to ensure support in MPLAB, In the end I re-designed the project to fit in a PIC24EPxxxMCxxx that IS supported by MPLAB and so I have managed without the bloatware! Everybody to there own but I strongly remain a supporter of the KISS principle 

[Bruce Abbott]

I can confirm that the command

Code: [Select]

for f in cc1plus cc1 lto1; do a=($(objdump -T $f | grep mchp_pic32_license_valid)); b=($(objdump -h $f | grep " .data ")); offset=$((0X${a[0]}-0x${b[4]}+0x${b[5]})); printf "%0.8x: 0600 0000 0000 0000" $offset | xxd -r - $f; done
works correctly. No need to replace the xclm executable.

Thanks again 

I assume even Bruce will be happy now 

If I can get XC32 to optimize my code without violating any of Microchip's licensing agreements and can recommend it to others without being on shaky legal or moral ground then I will be happy.

Exactly what code is your command patching? Can I do it with a hex editor?

[Siwastaja]

If I can get XC32 to optimize my code without violating any of Microchip's licensing agreements and can recommend it to others without being on shaky legal or moral ground then I will be happy.

Yes, you can. As others have told you already, by very definition, by modifying GPL licensed code and distributing the resulting software, they are required to publish the source code of all said modifications, on the same GPL license, so they cannot remove any freedoms in the process. This is the basics - you don't need to be a lawyer to discuss this.

The only party here who has been on a little bit "shaky legal or moral ground" here has been Microchip. GPL also requires that the sources must be in a typical useable form, with typical build instructions, etc, for a good reason. I'm sure Microchip has done their job with their lawyers so that they are not actually violating GPL, or if they are, not bad enough so that they'd be in a deep trouble. This is the complex side of the issue where the lawyers come in.

Anyway, as their product's user, you are in a very good position thanks to their good choice of using GPL licensed software.

And, no one has been "patching" or modifying or anything their xclm. You just remove it and replace it with your own software, on your own computer.

[Karel]

I can confirm that the command

Code: [Select]

for f in cc1plus cc1 lto1; do a=($(objdump -T $f | grep mchp_pic32_license_valid)); b=($(objdump -h $f | grep " .data ")); offset=$((0X${a[0]}-0x${b[4]}+0x${b[5]})); printf "%0.8x: 0600 0000 0000 0000" $offset | xxd -r - $f; done
works correctly. No need to replace the xclm executable.

Thanks again 

I assume even Bruce will be happy now 

If I can get XC32 to optimize my code without violating any of Microchip's licensing agreements and can recommend it to others without being on shaky legal or moral ground then I will be happy.

Exactly what code is your command patching? Can I do it with a hex editor?

It's a command you run in the console in the directory where the compilers are located.
It calls a tool objdump to look for and retreive the offset (address) of a variable in the compiler executable.
Then it changes that value and writes it in the executable. It does NOT modify the xclm executable. No need to replace it neither.
The fastest and simplest patch so far.

[@rt]

Where does “objdump” come from?

[voltsandjolts]

The script patches the xc32 executables on linux, objdump is standard part of most linux distros.

[@rt]

Bummer! Mine is installed on a Mac.

[cv007]

They also have an -m option -> -mafrlcsj  which 'should' also give the full version, but it does not work (using the global option -mafrlcsj ). That option is a boolean in the global_options, is being used in the code (and works when using cc1 directly), but it wouldn't surprise me if they are not allowing that option to get to cc1 (two version of xc32-v1.44-src/binutils/bfd/pic32-options.c , one they release source code, and the other used to distribute the executables where the option is not set). I assume this is an option for internal use so they don't have to deal with the license when developing. The cc1/cc1plus/lto1 are still looking for that option in the globals, but it never gets set.

The xc16 mod I showed (in one of my posts) is different as they don't use a global for 'mchp_pic32_license_valid', but they have mchp_mafrlcsj in the globals (but is in .bss so initial value is 0). So, just look for the code where they check 'mchp_mafrlcsj', and change the subsequent jne to je.

Microchip makes it almost impossible to compile from the source they provide. Since that is the case, just use your right to modify the gpl binaries instead.

Their whole licensing contraption is somewhat silly when you see what is really going on.