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)