Author Topic: Bug Infested Bloated Compilers  (Read 14990 times)

0 Members and 1 Guest are viewing this topic.

Offline VK3DRBTopic starter

  • Super Contributor
  • ***
  • Posts: 2252
  • Country: au
Bug Infested Bloated Compilers
« on: October 03, 2016, 12:09:50 pm »
I used to use the trusty old MPLAB, but today I needed to develop code for the new 16F18323, which is a very nice chip feature-wise, for low cost 8 bit micro. MPLAB does not seem to support it, but MPLAB X does. So I installed MPLAB X - bloatware extraordinaire, almost as bloated as Atmel's Studio 7. I used the MPLAB XC8 compiler and their graphical code wizard addon.

MPLAB XC8 compiler (or the IDE) had this bug with this line in main():

getch();                  // No problems compiling

char ch = getch();        // Blows up with a 712 "can't generate code for this expression" error.


Nothing wrong with the function or prototype char getch(void); which was created by the Graphical Code Generator to get a character from a EUSART receive character interrupt.

I wasted at least a couple of hours trying to work out what was wrong. Search the Internet. Nothing particular. Paths maybe? Restarting the program does nothing. I eventually reboot the PC for another reason. Voila! Problem gone. What crap. So what more bugs are there? I feel like swapping to the more expensive pin-compatible 16F1823 just to get the job done under MPLAB 8.

As bloated as Atmel Studio 7 is, it seems pretty robust and has some nice features. I compiled a fairly complicated piece of code for an Atmel ATxmega128A1 and it worked fine. That IDE is bigger than Texas. Why does a C code environment need a Microsoft based spell checker that is built in? In any case, it appears they have done a reasonable job, except for the bloat.

The king of bloatware compilers is Microsoft's Visual Studio Community Edition, installed over old Visual Studio versions. It's a Community Edition alright, a community of bugs you can't kill. What a bloody mess. Uninstall everything. Clean the registry. Different bugs. Lather. Rinse. Repeat. Still dirty. After a day of stuffing around, install on another machine - it works. Maybe Weird Al Yankovic can do a video on Visual Studio I'm Fat Edition.

I think decent companies (that excludes Microsoft for a start) should adopt the paradigm of KISS (Keep It Simple, Stupid). Instead they try to be all things to all people in one bloated package. That is why I liked the old MPLAB. It just bloody worked.

OK, they are "free" except for the time wasted. Should I quit complaining because these IDE's/compilers are free and not properly tested, ie: use at your own peril? Or should we expect more, because we are buying their chips and using the compiler to sell more of their product? Not sure what paradigm to use, but I dislike all the glitz, glamour, adverts, and "Where do you want to go to today" bloatware. I just want a tight, efficient, fast and easy to use, and above all, reliable compiler, using for example Notepad++ and/or Eclipse for the editor. Am I asking too much? Have these companies lost the plot, or am I just getting old and grumpy?
« Last Edit: October 04, 2016, 11:34:54 pm by VK3DRB »
 

Offline setq

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: gb
Re: Bug Infested Bloated Compilers
« Reply #1 on: October 03, 2016, 12:30:11 pm »
I spent ten years in front of Visual Studio with stupid large solutions (2-8 million lines of C#/C++). I spend most of my time in front of Vim now.  I couldn't agree more with your assertions.  I've gone from 10-20 crashes/showstopping bugs a day to perhaps 1 every couple of months now.

The stupid thing is the entire VS IDE is still only a 32-bit binary so it can't address more than a couple of GiB of RAM. This causes it to destroy itself occasionally. Then when you install things like Resharper, wham it won't even open a large project without crashing.

Unix/Linux is an IDE. tmux is the window manager. vim is the editor. make/gcc is the build toolchain. python is the scripting language. bash is the glue. Everything existing apart yet working in complete unity.
« Last Edit: October 03, 2016, 12:31:51 pm by setq »
 

Offline Marinated

  • Contributor
  • Posts: 27
  • Country: nz
Re: Bug Infested Bloated Compilers
« Reply #2 on: October 03, 2016, 12:35:51 pm »
May the powers that be hear your voice.

This is what you get when a generation of programmers who had no choice but to write high-performance code exits the stage and is replaced by a pack of clowns raised on Java.  Once upon a time, high-performance code was the only kind that worked, because hardware was so feeble.  I'm not blaming young programmers as a group, those at the top are as brilliant as those of yesteryear.  However, it's clear that the number of people writing code has exploded, and there is a lower barrier for entry.

On top of that you can add the effects of test-driven development, which works for a good team but will not make a bad one better.  Who tests the tests? They are often written by the same people who write the code, leaving them prone to the same thought errors, and resulting in bugs merely being shifted out of the code proper into the test harness. These problems can be dealt with in a good team, but the test-driven framework is often worshipped and seen as a guarantee of correctness.

The problems with bad code at Microsoft in particular are well documented by former employees who complained of a culture hell-bent on new features, and that actually rewarded inventive circumventions of bugs more than fixing the bugs themselves.

Try profiling one of these bloatware applications and watch it spend most of its time doing method dispatching.
« Last Edit: October 03, 2016, 12:37:47 pm by Marinated »
 

Offline setq

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: gb
Re: Bug Infested Bloated Compilers
« Reply #3 on: October 03, 2016, 12:39:09 pm »
As someone who has jousted with the 800 line Java stack trace a few times in my years, hell yes to all of that.
 

Offline paf

  • Regular Contributor
  • *
  • Posts: 91
Re: Bug Infested Bloated Compilers
« Reply #4 on: October 03, 2016, 12:46:59 pm »
Just tested this on XC8  version 1.38 on OS X  (with the required processor)  and it works ok:

char getchar(){
     return 'a';       
   };
int main()

{
  char c=getchar();
  return 0;
}       


So, is the error somewhere else?

P.S.: I also don't like HUGE IDEs.
 

Offline Towger

  • Super Contributor
  • ***
  • Posts: 1645
  • Country: ie
Re: Bug Infested Bloated Compilers
« Reply #5 on: October 03, 2016, 01:34:52 pm »
Once apon a time I thought VB6 was bloat ware...

What drives me mad with MS is they only listen/hear the people who live and breath software development and attend all their events, in search of the latest new (unfinished) technology to play with.

In reality the bulk of development is maintaining large existing systems, which are too large and complex to rewrite every time they abandon a technology for the new flavor of the day.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Bug Infested Bloated Compilers
« Reply #6 on: October 03, 2016, 01:38:24 pm »
I too have seen occasional XC8 bizarreness like this, often in seemingly benign scenarios, but it's the exception rather than the rule. I can't ever remember a reboot or restart fixing it though.

XC8 does work in MPLAB 8.92, even the current 1.38, but the old IDE doesn't know anything about the relatively new PIC183xx series, which generally puts it off-limits.

Regarding the blight of bloatware IDEs, I totally agree that there's a correlation between those written using managed language/framework combos such as Java and C# and general slowness, and general lack of care over machine resource usage. I am not sure how much of this is due to the framework itself, and how much is due to the libraries themselves, and a lack of understanding how those libraries use resources.

There are also silly things in the design of MPLAB X and Netbeans themselves, which insists on parsing everything under the sun, and doesn't deem to be possible to turn it off. As soon as you load up a fairly minimal (!) Harmony app, unless you're using a reasonably pokey machine you'll be suffering from a general lack of responsiveness and excessive CPU use.

However, if I may, if you ever had the misfortune to run Microsoft's Programmer's Workbench (PWB) IDE back around 1990, all can be forgiven. This was an attempt to answer Borland's IDEs (which had an extremely good reputation among developers), and has to be the worst one I've ever used, it was almost unusable it was so slow, I mean really slow.
 

Offline setq

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: gb
Re: Bug Infested Bloated Compilers
« Reply #7 on: October 03, 2016, 01:50:44 pm »
Regarding the blight of bloatware IDEs, I totally agree that there's a correlation between those written using managed language/framework combos such as Java and C# and general slowness, and general lack of care over machine resource usage. I am not sure how much of this is due to the framework itself, and how much is due to the libraries themselves, and a lack of understanding how those libraries use resources.

All of the above. Primarily grounded in the sheer headroom these platforms give you with the crazy high performance and maintainability but only up to a point. When you hit the wall, the complexity takes you down.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13693
  • Country: gb
    • Mike's Electric Stuff
Re: Bug Infested Bloated Compilers
« Reply #8 on: October 03, 2016, 01:57:27 pm »
I too have seen occasional XC8 bizarreness like this, often in seemingly benign scenarios, but it's the exception rather than the rule. I can't ever remember a reboot or restart fixing it though.

XC8 does work in MPLAB 8.92, even the current 1.38, but the old IDE doesn't know anything about the relatively new PIC183xx series, which generally puts it off-limits.

Regarding the blight of bloatware IDEs, I totally agree that there's a correlation between those written using managed language/framework combos such as Java and C# and general slowness, and general lack of care over machine resource usage. I am not sure how much of this is due to the framework itself, and how much is due to the libraries themselves, and a lack of understanding how those libraries use resources.

There are also silly things in the design of MPLAB X and Netbeans themselves, which insists on parsing everything under the sun, and doesn't deem to be possible to turn it off. As soon as you load up a fairly minimal (!) Harmony app, unless you're using a reasonably pokey machine you'll be suffering from a general lack of responsiveness and excessive CPU use.

However, if I may, if you ever had the misfortune to run Microsoft's Programmer's Workbench (PWB) IDE back around 1990, all can be forgiven. This was an attempt to answer Borland's IDEs (which had an extremely good reputation among developers), and has to be the worst one I've ever used, it was almost unusable it was so slow, I mean really slow.
For similar parts it is possible to tweak things to make MPLAB 8.92 work with them.

I have a feeling that addding actual new parts is hard but you can tweak definitions of other parts you don't use, e.g. I added PIC32MX170 support which my MPLAB thinks is a 32MX150F128C
From memory think it just involved tweaking the default XC32 linker file to addd the extra memory, and a file that tells MPLAB the device ID fpr programming

I also hate big IDEs - by all means have stuff you can install later if you want, but just include the basics in the default setup, and don't insisty I bury everything in gazillions of folders.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline HackedFridgeMagnet

  • Super Contributor
  • ***
  • Posts: 2028
  • Country: au
Re: Bug Infested Bloated Compilers
« Reply #9 on: October 03, 2016, 01:58:41 pm »
As someone who has jousted with the 800 line Java stack trace a few times in my years, hell yes to all of that.
OMG, I must have only been a squire, I jousted with mere ~90 line call stacks. After a while you learn where to look though.

I really like VS very very few crashes  :-+,  also like Eclipse  :-+ but was fighting XC8 and MPLab whatever today, it's a bit more primitive, and you get that insane message about the  Omniscient Code Generation, WTF is that?
« Last Edit: October 03, 2016, 02:05:25 pm by HackedFridgeMagnet »
 

Offline djacobow

  • Super Contributor
  • ***
  • Posts: 1151
  • Country: us
  • takin' it apart since the 70's
Re: Bug Infested Bloated Compilers
« Reply #10 on: October 03, 2016, 09:13:44 pm »
I spend most of my time in front of Vim now. 

Another vote for Vim + command line tools.

Vim is also quite interesting in that it has a bunch of cool plugins out there, which you can install if you want them. In addition to the syntax highlighting built in, syntastic will check your code's syntax in a bunch of language, youcompleteme, for autocompletion, various beautifiers, git-wrappers like fugitive, etc. I'm really happy with the ecosystem, and if any of that vim add-on crap bugs me, I turn it off and keep working.
 
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Bug Infested Bloated Compilers
« Reply #11 on: October 03, 2016, 09:37:29 pm »
"MPLAB XC8 compiler (or the IDE) had this bug with this line in main():"

Your experience is quite common. Apparently finding bugs iss quite easy, especially with novice programmers.

================================
https://dannyelectronics.wordpress.com/
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2536
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: Bug Infested Bloated Compilers
« Reply #12 on: October 03, 2016, 10:16:13 pm »
I am always hesitant about installing a chip company's IDE (after getting burnt many times in the past), but PSoC Creator has been a very pleasant surprise. It starts quickly, works quickly and has never crashed on me. It's easy to use and well laid out. I like it a lot.

The absolute worst for me is Code Composer Studio (more like Crapy Compost Shit amirite), which is a 20+GB abomination! It's a Java based pile of trash. Wrestling with it makes me so angry... If it were a person, I'd make a Human Centipede out of it (with Visual Studio being the front; then I'd force feed VS spicy Mexican food and laxatives). That's the kind of hell CCS deserves.

Fuck CCS.
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Bug Infested Bloated Compilers
« Reply #13 on: October 03, 2016, 11:29:05 pm »
Quote
saves tons of cost and time compared to developing your own IDE from scratch

no need to worry too much about that: people who talk a lot about developing their own IDEs from scratch are generally those who are least capable of developing their own IDEs.
================================
https://dannyelectronics.wordpress.com/
 

Offline VK3DRBTopic starter

  • Super Contributor
  • ***
  • Posts: 2252
  • Country: au
Re: Bug Infested Bloated Compilers
« Reply #14 on: October 03, 2016, 11:34:04 pm »
Those who wrote the MPLAB Code Configuator obviously have never tested it properly. The code generated for adc.c is blank, even if there are no warnings.

Anyone who has used the CodeVision/AVR will know its code wizard is superb. It sets all the registers and comments the lines beautifully. It written by a Romanian for whom English is not his first language. One bloke who created a great compiler. Compared to CodeVision/AVR this MPLAB Code Configurator is crap. Unfortunately CodeVision is for AVR's, not PICs.

STOP PRESS: I found the root cause of the problem: I  used Microchip's Code Configurator. How utterly silly of me. It will be faster for me to write the code the old way, reading the datasheet.
« Last Edit: October 03, 2016, 11:48:10 pm by VK3DRB »
 

Offline eugenenine

  • Frequent Contributor
  • **
  • Posts: 865
  • Country: us
Re: Bug Infested Bloated Compilers
« Reply #15 on: October 04, 2016, 12:46:14 am »


So, is the error somewhere else?



He said he rebooted and the error went away.

therefore isolating the the problem to a bug infested bloated OS not the compiler :P
 

Offline VK3DRBTopic starter

  • Super Contributor
  • ***
  • Posts: 2252
  • Country: au
Re: Bug Infested Bloated Compilers
« Reply #16 on: October 04, 2016, 06:54:46 am »
STOP PRESS: I found the root cause of the problem: I  used Microchip's Code Configurator. How utterly silly of me. It will be faster for me to write the code the old way, reading the datasheet.

It is not clear (to me) how this would not work and then work on either side of a reboot.

Probably a registry issue with the program. I am going ahead with the MPLAB X with its bugs because I want to use the steerable PWM features that 16F18323 chip has over the PIC16F1823. Plus the 18323 is about 20 cents cheaper than the 1823 for this mildly cost sensitive project. 

Found another bug in MPLAB X. Clicked on refactor a function name. Refactoring slider came up as 50% done and hanged the program. CTRL-ALT-DEL again. At least it saved everything from the previous recompile.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Bug Infested Bloated Compilers
« Reply #17 on: October 04, 2016, 07:42:30 am »
For similar parts it is possible to tweak things to make MPLAB 8.92 work with them.

I have a feeling that addding actual new parts is hard but you can tweak definitions of other parts you don't use, e.g. I added PIC32MX170 support which my MPLAB thinks is a 32MX150F128C
From memory think it just involved tweaking the default XC32 linker file to addd the extra memory, and a file that tells MPLAB the device ID fpr programming


I did the exact same thing for the MX270, worked a treat.

I did look into doing a similar trick for the 16F183xx series, but ISTR when I looked at the programming protocols they were different enough to other supported devices that I considered it not reasonably feasible to come up with a hack to use with MPLAB 8, but ISTBC.
 

Offline senso

  • Frequent Contributor
  • **
  • Posts: 951
  • Country: pt
    • My AVR tutorials
Re: Bug Infested Bloated Compilers
« Reply #18 on: October 04, 2016, 09:43:34 am »
2,79 GB is bigger than Texas?
Used vim+cmd, changed a long time ago to the AS6 and now 7, and I would rather spend my time with AS6 than using vim and 100 different cmd tools to have the same things..
I hate Eclipse based crap though..
And with ssd's so cheap right now, putting the base OS and the most used programs in one is a good idea.
 

Offline VK3DRBTopic starter

  • Super Contributor
  • ***
  • Posts: 2252
  • Country: au
Re: Bug Infested Bloated Compilers
« Reply #19 on: October 04, 2016, 11:58:38 am »
I hate Eclipse based crap though..

Eclipse has a major problem dealing with large multi-file projects when refactoring. It loses the plot where if for example you have a function name, constant or variable used in, say a few hundred places, Eclipse will on occasion refactor some and not others. You only find out if it stuffed up on recompiling. Worse still, if on the odd chance you wanted to swap identifiers, your project might be screwed up and your have to do a revert using SVN or whatever. But Eclipse free. Use at own risk.

What is not acceptable is Altium charging for bug fixes via a subscription. You pay $10K, bugs are thrown in for free and you have to keep on paying subscriptions to get them fixed. A bad business model that cheeses customers off. For ten grand, bug fixes should be free forever and you only pay for upgrades that have new features.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Bug Infested Bloated Compilers
« Reply #20 on: October 04, 2016, 01:28:04 pm »
STOP PRESS: I found the root cause of the problem: I  used Microchip's Code Configurator. How utterly silly of me. It will be faster for me to write the code the old way, reading the datasheet.

I'm not at all surprised. TBH, in the end MCC is rarely worth the hassle. At the end of the day you _have_ to understand your peripherals to a reasonable level at the hardware and register level anyway, so the value of MCC is limited.

Here are my reasons _not_ to use MCC, in no particular order:

o Strait-jacketed code organisation;
o Bugs;
o Missing peripheral functionality;
o Lack of forward and backward compatibility between MCC releases;
o Over-complex, jack-of-all-trades drivers (e.g., I2C);
o Difficulty of maintaining your own code inside its machine generated code (you're continually at risk of it over-writing your code);
o You spend more time debugging MCC generated code than if you'd written your own;
o Even the simplest project creates multiple source files, making it very difficult to narrow down anomalies to small succinct self-contained reproducible code snippets - as we have found here!
o Generates bulk peripheral SFR assignment code with comments, but doesn't separate them out into a field-by-field human-readable result;
o You still need to understand how the peripherals work!

Reason to use MCC:

o Possibly marginally quicker to get very very basic prototypes working once you've learned how to use it.

In general, any code generator you should use at your own risk, and take time to understand its limitations. While a few, like Visual Studio's Visual C++ forms code generator, work reasonably well, those that do work well also properly manage to differentiate between machine and developer generated code. The same cannot be said for MCC.

 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: Bug Infested Bloated Compilers
« Reply #21 on: October 04, 2016, 01:53:26 pm »
STOP PRESS: I found the root cause of the problem: I  used Microchip's Code Configurator. How utterly silly of me. It will be faster for me to write the code the old way, reading the datasheet.

It is not clear (to me) how this would not work and then work on either side of a reboot.

Probably a registry issue with the program. I am going ahead with the MPLAB X with its bugs because I want to use the steerable PWM features that 16F18323 chip has over the PIC16F1823. Plus the 18323 is about 20 cents cheaper than the 1823 for this mildly cost sensitive project. 

Found another bug in MPLAB X. Clicked on refactor a function name. Refactoring slider came up as 50% done and hanged the program. CTRL-ALT-DEL again. At least it saved everything from the previous recompile.
maybe something is wrong with your computer?
I've been using X since it came out, on different machines and different OS. Every time a new version introduced stupid bugs that required you to reboot the application a newer version came out a couple of days later that addressed the problem.
Despite some idiocies that were never addressed, i like it far more than the old mplab (that by the way needs a to be rebooted frequently here)
 

Offline Jeff_Birt

  • Regular Contributor
  • *
  • Posts: 198
  • Country: us
Re: Bug Infested Bloated Compilers
« Reply #22 on: October 04, 2016, 01:56:33 pm »
Part of the issue with what is seen as bloat is to maintain backwards compatibility. C++ is a prime example of this, they try very hard with both the language and compilers to never break old code. So if there was a stupid screwy way of doing something in 1989 it will never go away, hence you still have guys writing C++ code like they would have in 1989 so the language specs and compilers have to handle all that old cruft.

Specific to Microchip, they have what 500ish current part numbers, with multiple versions, plus discontinued parts still supported, each of those probably has at least ten work-arounds for silicone bugs, so you have an enormous number unique parts they are trying to support, and work around silicone bugs which becomes an even more enormous problem as time goes on. Given that there will be software bugs as well in the development tools you have a real mess. I'm sure someone can lash together some other tool set that works great for them on a limited series of parts but pales in comparison to what the factory dev tool support.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Bug Infested Bloated Compilers
« Reply #23 on: October 04, 2016, 03:29:53 pm »
Part of the issue with what is seen as bloat is to maintain backwards compatibility. C++ is a prime example of this, they try very hard with both the language and compilers to never break old code. So if there was a stupid screwy way of doing something in 1989 it will never go away, hence you still have guys writing C++ code like they would have in 1989 so the language specs and compilers have to handle all that old cruft.

Specific to Microchip, they have what 500ish current part numbers, with multiple versions, plus discontinued parts still supported, each of those probably has at least ten work-arounds for silicone bugs, so you have an enormous number unique parts they are trying to support, and work around silicone bugs which becomes an even more enormous problem as time goes on. Given that there will be software bugs as well in the development tools you have a real mess. I'm sure someone can lash together some other tool set that works great for them on a limited series of parts but pales in comparison to what the factory dev tool support.

I'm not sure I agree: MPLAB X has always been a dog, even when it was supported at the same time as MPLAB 8.x. Just compare the compile times, load times, debugger/programmer communication times, for examples off the top of my head. It's the same compiler, just to shell out from Java is extraordinarily slow compared to the native code MPLAB 8.

I suspect it's because Java and C# programmers don't need to understand pointers, so passing by reference is used far less, instead passing enormous structures about by value. That would explain both both performance and memory hogging.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: 00
Re: Bug Infested Bloated Compilers
« Reply #24 on: October 04, 2016, 03:49:18 pm »
MPLAB X has always been a dog, even when it was supported at the same time as MPLAB 8.x. Just compare the compile times, load times, debugger/programmer communication times, for examples off the top of my head. It's the same compiler, just to shell out from Java is extraordinarily slow compared to the native code MPLAB 8.

1.) Compile times can be longer because of the licence check Microchip built in into GCC.
Some people noticed improved compile times when replacing the license check binary with a simple executable that returns immediately.
This is easy to do with the information somewhere else on this forum.

2.) Startup time of the IDE is 16 seconds (no SSD). I find this acceptable for a program that I usually start once a day.

3.) Programmer communication time is long with the PK3. With the ICD3 it's much better. Only when you change the target, new firmware will be loaded which takes some extra time.

I suspect it's because Java and C# programmers don't need to understand pointers, so passing by reference is used far less, instead passing enormous structures about by value. That would explain both both performance and memory hogging.

People who don't understand the concept of pointers to pointers aren't programmers...
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf