No more code-size-limited version of IAR embedded workbench for ARM?

[NorthGuy]

A measure for crappiness can be absence of structuring, consistency, presence of hacks to coerce the compiler into doing what you think it should do, like  abusing globals and volatile, mixing C and assembly when there is almost always a better/proper way to do things, difficulty in adding functionality as it will have side effects on other parts of code that are difficult to change because of all the above.
In the last few years i rewrote several of my old firmwares from the ground up. About 80-85% of the time spent to define the actual behaviour to replicate (i.e.: specification), 10% for A/B testing and 5% actual coding, since then adding new features has been much, much easier.
The embedded muse was full of such cases and examples, a rewrite of problematic software can have a "high" initial cost (which, again, is defining in detail the actual specifications of the current firmware), but pays off almost immediately.

I also spend most of the time on designing, and relatively little time on coding.

However, I don't think a "proper" way of doing things exists, and, if necessary, I would do whatever it takes to coerce the compiler to implement my design exactly as I want it. But, most of the time (like 99.9%) I simply write to C99 standard and it works.

[Siwastaja]

But, most of the time (like 99.9%) I simply write to C99 standard and it works.

This is the key. It seems that very small percentage of programmers seem to be in constant fight against GCC, yet most do fine.

And the latter group includes the most demanding users of GCC in projects like linux kernel, who indeed have had fights with GCC, but still understand that they do not want to go back to 1980's or switch compilers.

And if asked to enumerate their actual gripes, as in this thread, it's always the same story: 1% actual GCC stupidness, 99% of unnecessary complaining (often complaining Just In Case even when everything works normally).

If working with gcc is so difficult as it is to a few individuals here, I would suggest looking in the mirror for a chance. I mean, blaming others by default is a natural human coping mechanism but it really isn't a way forward. Not only will these people lose their internet fights, they will also not be able to deliver good software because they spent on their time inefficiently blaming others and never learning.

[peter-h]

Time to get out of reading this thread, with the repeated insinuations by Siwastaja that somebody is some kind of a retard.

[cfbsoftware]

Time to get out of reading this thread, with the repeated insinuations by Siwastaja that somebody is some kind of a retard.

Excellent idea. This might help to put it into perspective:

https://www.xkcd.com/1048/

[5U4GB]

Time to get out of reading this thread, with the repeated insinuations by Siwastaja that somebody is some kind of a retard.

They're either a gcc maintainer or have the attitude of the gcc maintainers, "we're soooo much cleverer than you and anything that happens is your fault because you're an idiot".

Maybe we need a new thread, "Discussion about safe compilers for use with mission-critical code" or similar?

[Siwastaja]

They're either a gcc maintainer or have the attitude of the gcc maintainers, "we're soooo much cleverer than you and anything that happens is your fault because you're an idiot".

You miss one: have blamed others for own problems in the past, looked into mirror, started using common sense, and stopped panicking.

By common sense I mean this: gcc is used in mission critical software all the time. If this is so, can it really be possible that using GCC is equivalent to a car with no brake pedal? Of course not. So reconsider and check your arguments more carefully until things match with reality.

After blaming my tools (GCC and others) so many times and seeing later I was wrong, I feel like the least I can do is to investigate properly before blaming others. And as have been shown in this thread already, your complaints can be mostly proved wrong too; the only issue is that you are not willing to admit it. This does not negate the fact though that you are partially right.

If you are in search of a perfect tool / perfect compiler / perfect language, I have very sad news for you: it does not exist.

And don't forget what I already mentioned: I totally agree with you about gcc maintainer's attitude problems, it's a well documented phenomenon. You are just blowing it up to proportions that prevent you from going forward with your life and projects. You are creating excuses for yourself and others. And you are misleading people like peter-h who do not need any more rationalization of their made-up problems. You complaining and feeding others with poorly laid out, mostly made-up complaints helps no one. If you find gcc developers attitude causes problems to others, how about questioning what your attitude does to yourself - and others.

[nctnico]

Time to get out of reading this thread, with the repeated insinuations by Siwastaja that somebody is some kind of a retard.

They're either a gcc maintainer or have the attitude of the gcc maintainers, "we're soooo much cleverer than you and anything that happens is your fault because you're an idiot".

Maybe we need a new thread, "Discussion about safe compilers for use with mission-critical code" or similar?

You should add to that: 'for programming languages people actually want to use'. Ada has been around for a long time and it was developed for doing mission critical stuff. For some reason people wanted to re-invent this wheel and call it Rust. In the meantime microcontrollers have become fast enough to run Python; a language half the world knows how to program in and doesn't have all the pitfalls C/C++ expose a software developer to.

[5U4GB]

It depends on what you see as the biggest problem you're dealing with.  Ada for example is a well-designed language but has very little tool or industry support compared to what C has.  I think something like Eiffel or the early Modulas before they went off into the weeds are even nicer but have even less support.  Also in some cases you want C as a high-level assembler with very precise control over what's going on, which high-level features like Rust's memory management that hide all of that can't give you - it's a feature for some but an anti-feature for others.

Another big issue is that if your entire environment is C then you can't afford to be the one pushing for your favourite language, or at least not if you expect to still have customers.

[nctnico]

Another big issue is that if your entire environment is C then you can't afford to be the one pushing for your favourite language, or at least not if you expect to still have customers.

Interestingly it has been the other way around for several projects I have made. I have implemented Lua and (more recently) Python scripting support to allow customers to modify the high level function in an easy way. The customers didn't want to mess with C and compilers at all. Just upload a new script. IMHO you can't say C / C++ are the defacto programming languages in general nowadays. And I think this has been the case for at least 10 years. At the same time I'm quite sure C/ C++ will stick around for a very long time.

[Siwastaja]

I have implemented Lua and (more recently) Python scripting support to allow customers to modify the high level function in an easy way. The customers didn't want to mess with C and compilers at all. Just upload a new script.

If you have technical resources to enable this, it's a winner recipe. But it does require quite some resources for the interpreter, and specification how it interfaces with the lower level stuff. But if you have something like a general-purpose single-board computer already running linux then this is pretty easy to pull off.

There is something to be learned from the game industry: they already came up with simple scripting languages in mid-90's, while the game engine itself was really tightly optimized (and closed-source) C++. But the scripting extension allowed even quite complex "mods" resembling a new unique game altogether to be made.

[nctnico]

I have implemented Lua and (more recently) Python scripting support to allow customers to modify the high level function in an easy way. The customers didn't want to mess with C and compilers at all. Just upload a new script.

If you have technical resources to enable this, it's a winner recipe. But it does require quite some resources for the interpreter, and specification how it interfaces with the lower level stuff. But if you have something like a general-purpose single-board computer already running linux then this is pretty easy to pull off.

Actually, Python and Lua are designed to be add-on languages to C. So interfacing between scripted and none-scripted code is very easy to implement. And no, you don't need a single board computer. A microcontroller with 128k flash and 64k RAM is enough to run Lua scripts + compiler on. Double that for Micropython. There is also the option to pre-compile the scripts into byte code and run that so you can leave the compiler out but I never bothered to do that.

[NorthGuy]

I have implemented Lua and (more recently) Python scripting support to allow customers to modify the high level function in an easy way. The customers didn't want to mess with C and compilers at all.

Of course. If someone cannot write in C they have to use something else.

[SiliconWizard]

Lua is great for scripting with a low footprint, but still definitely requires some code and RAM space - not a fit for very small MCUs. Also, "embedded" Lua almost always requires not using Lua tables (as these are allocated dynamically and can be quite "hungry" in terms of RAM), and frankly, to me (a now long-time and happy user of Lua), Lua without tables is like, uh, C without pointers. Tables are IMO really the core of Lua. But certainly, a subset of Lua can still be used for simple scripting. I'm curious to know what users of embedded Lua think about that.

Regarding selling products with "programmability", I agree that, unless you target only pro users in a specific niche, giving programmability with C and at the firmware level (I mean, you could always provide a C interface and only allow some kind of "plugins" while not giving access to the full firmware, which is already a bit less painful) can be a nightmare, and simple scripting is much, much easier both for the customers and for the vendor.

[5U4GB]

Interestingly it has been the other way around for several projects I have made. I have implemented Lua and (more recently) Python scripting support to allow customers to modify the high level function in an easy way.

Lua is pretty nice as a C add-on, but that also requires customers who want to do the programming themselves rather than paying the vendor to do it for them.  I've been involved in a couple of projects where the techies had a lot of influence on development and decided to make it programmable so it'd be really flexible and cool and extendable, and then after spending a fortune on it found that what users wanted was an out-of-the-box solution which their competitors with their non-programmable devices were selling for a fraction of the price.

To put it another way, given the choice between Home Assistant ("welcome to your new hobby!") and, say, HomeKit or WeMo ("welcome to your smart home"), most people would choose the latter.

[nctnico]

Interestingly it has been the other way around for several projects I have made. I have implemented Lua and (more recently) Python scripting support to allow customers to modify the high level function in an easy way.

Lua is pretty nice as a C add-on, but that also requires customers who want to do the programming themselves rather than paying the vendor to do it for them.  I've been involved in a couple of projects where the techies had a lot of influence on development and decided to make it programmable so it'd be really flexible and cool and extendable, and then after spending a fortune on it found that what users wanted was an out-of-the-box solution which their competitors with their non-programmable devices were selling for a fraction of the price.

That is called 'feature creep'; a different problem.

The trick to succesfully embed a form of scripting is not to implement it as an add-on but use it to implement the high level logic by design. That way you don't lose any development time AND satisfy customer requirements at the same time. Also, the customer isn't required to program anything by themselves. They can use the manufacturer provided script but they have the to option to modify the script if they want to.