nuttx - "linux" on a microcontroller

[farsi]

I recently saw this: https://acassis.wordpress.com/2015/09/12/testing-an-rgb-led-in-the-nuttx/ - nuttix is
a RTOS (not sure how exactly).

The build process is described here (google translate to get a feeling for it): http://www.bubuko.com/infodetail-1092724.html

I was trying the build on an Ubuntu machine, but I get stuck somewhere near the pass2deps Makefile task. I'll retry later.

Maybe someone here has already experiences with Nuttx ? What do you think?

[codeboy2k]

I've never used it, but apparently it works on the Z8 Encore , and I happen to have one of those lying around from the early 2000s

So I'll have to give it a try myself too !

[farsi]

that is a nice board   

so, I had to refresh about what happened to zilog after the z80 https://en.wikipedia.org/wiki/Zilog

[codeboy2k]

so, I had to refresh about what happened to zilog after the z80 https://en.wikipedia.org/wiki/Zilog

Re: Zilog Z8 Encore:

I have long thought these micros were discontinued or obsoleted, but it turns out you can still buy them from Digikey, and the Zilog site still lists them as active.  They might have a niche market still, but they are not going to be competitive anymore, compared to more recent micros.

[janoc]

linux isNotEqualTo RTOS

NuttX != Linux neither.  Those quotes were fairly justified. Nothing to do with Linux whatsoever. And yes, it is an RTOS.

http://nuttx.org/

[codeboy2k]

Yes, it is an independently developed RTOS, not Linux.. I'll still fire it up on the dev board in the picture and see if it flies

The dev tools are over 13-14 yrs old now, so I'll save myself some hassle and just start out trying to load it up in an XP virtual machine.

... yeah, it needs XP and Cygwin.... and a serial port to download it

Code: [Select]

configs/z8encore000zco
  z8Encore! Microcontroller.  This port use the Zilog z8encore000zco
  development kit, Z8F6403 part, and the Zilog ZDS-II Windows command line
  tools.  The development environment is Cygwin under WinXP.

I hope it doesn't need a specific version of Cygwin from the early 2000's.  Since I recall Cygwin installs by pulling packages from a server online, it might be hard to get a specific version from the early 2000's running -- if so I'll need to find an already installed snapshot somewhere.  I don't mind running the build and letting it install while I am doing other things, but I don't really want to spend time to port the build system to a modern Cygwin. 

[farsi]

From http://www.nuttx.org/Documentation/NuttX.html

NON-GOALS: (1) It is not a goal to provide the level of OS features like those provided by Linux. In order to work with smaller MCUs, small footprint must be more important than an extensive feature set. But standard compliance is more important than small footprint.Surely a smaller RTOS could be produced by ignoring standards.  Think of NuttX is a tiny Linux work-alike with a much reduced feature set. (2) There is no MMU-based support for processes. At present, NuttX assumes a flat address space.

[farsi]

about getting started this looks nice http://lc.orbitalfox.com/~fox/getting_started_for_nuttx_development_on_linux./ and  http://www.zilogic.com/blog/tutorial-nuttx-hello.html

[mikerj]

From http://www.nuttx.org/Documentation/NuttX.html

NON-GOALS: (1) It is not a goal to provide the level of OS features like those provided by Linux. In order to work with smaller MCUs, small footprint must be more important than an extensive feature set. But standard compliance is more important than small footprint.Surely a smaller RTOS could be produced by ignoring standards.  Think of NuttX is a tiny Linux work-alike with a much reduced feature set. (2) There is no MMU-based support for processes. At present, NuttX assumes a flat address space.

The phrase "Linux work-alike" is used to describe the concept of this RTOS, it does not mean it's actually a tiny version of Linux.  It implements POSIX standards for task control, file systems, semaphores etc. like Linux does, but it's absolutely NOT Linux.

[donotdespisethesnake]

Well, I think we all agree Nuttx is an RTOS

I would say "it's a bit like an old Unix". But even old Unix had separate process space.

After looking at many RTOS offerings all with pretty idiosyncratic APIs, the POSIX aspect looks interesting. Certainly it should make porting code from vanilla Unix a bit easier, and perhaps moving from Nuttx to Linux (or other embedded Unix).

I think NuttX could nicely fill the gap between a very light RTOS like FreeRTOS, and an actual Linux/ucLinux.

[acassis]

I created some video tutorials explaining how to get started to NuttX, see it here:

https://www.youtube.com/channel/UC0QciIlcUnjJkL5yJJBmluw

All you need is a low cost board (less than U$2.00) :
https://aliexpress.com/item/Free-Shipping-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-Forarduino/32525208361.html

An ARM SWD Programmer (about U$2.25) :
https://aliexpress.com/item/ST-Link-V2-stlink-mini-STM8STM32-STLINK-simulator-download-programming-With-Cover/32277220832.html

And a USB/UART 3.3V adapter (less than U$ 1.50) :
https://aliexpress.com/item/CP2102-USB-2-0-to-TTL-UART-Module-6Pin-Serial-Converter-STC-Replace-FT232-Module/32534146426.html

The NuttX RTOS is very powerful, but it is similar Linux in 1992: very few people knows about it.

[rstofer]

That's a nice set of videos!  Thanks for sharing...

[bingo600]

I wonder why i should chose nuttx , instead of ie. FreeRtos

Isn't it just another Rtos

/Bingo

[janoc]

I wonder why i should chose nuttx , instead of ie. FreeRtos

Isn't it just another Rtos

/Bingo

Why don't you actually read the documentation and see for yourself? Compared to FreeRtos, Nuttx is a lot more advanced (e.g. supports SMP), has more ready-to-go drivers and subsystems, such as displays, terminal, networking, even a basic shell. It is targeting the more powerful micros with plenty of RAM, but a cut down version runs even on very small devices (like an AVR).

Whether or not is that relevant for your application is up to you to decide. FreeRtos is only the minimal RTOS "kernel", everything else is up to the user to implement (or to get from elsewhere). Nuttx is more comparable with VxWorks than FreeRtos.

[Sal Ammoniac]

Whether or not is that relevant for your application is up to you to decide. FreeRtos is only the minimal RTOS "kernel", everything else is up to the user to implement (or to get from elsewhere). Nuttx is more comparable with VxWorks than FreeRtos.

Looks like another typical open-source project with minimal documentation and forum-style support. Why would anyone use this in a commercial product rather than VxWorks or ThreadX unless they're a start-up with no funding?

[janoc]

Looks like another typical open-source project with minimal documentation and forum-style support. Why would anyone use this in a commercial product rather than VxWorks or ThreadX unless they're a start-up with no funding?

What gives you the idea it is targetting commercial products? It certainly can be used commercially (it is BSD licensed) but I don't think that is its main objective. I was comparing it to VxWorks only because someone asked about FreeRTOS - which really isn't in the same league, functionality-wise.

Re documentation - ehm, don't get me started on some commercial projects' documentation ...
BTW, the Nuttx documentation is fairly extensive, certainly way more detailed than a "typical open source project":
http://nuttx.org/doku.php?id=documentation:userguide
The subsystems have their own doc.

There is also this: https://github.com/engehcall/technology/blob/master/NuttX/nuttx-overview.pdf  (the file is a part of the Nuttx distribution)

Doesn't really seem to me like "minimal documentation" 

[Sal Ammoniac]

What gives you the idea it is targetting commercial products? It certainly can be used commercially (it is BSD licensed) but I don't think that is its main objective. I was comparing it to VxWorks only because someone asked about FreeRTOS - which really isn't in the same league, functionality-wise.

I'm not sure what they're targeting. It's not clear from reading their website. VxWorks is mentioned on their website, so I assumed they were at least partially targeting VxWorks users, who are almost entirely commercial.

Doesn't really seem to me like "minimal documentation" 

It's all relative. It appears minimal to me. Perhaps people are becoming used to the open-source model of documentation (i.e. little to none) and don't find this an issue.

[donotdespisethesnake]

Looks like another typical open-source project with minimal documentation and forum-style support. Why would anyone use this in a commercial product rather than VxWorks or ThreadX unless they're a start-up with no funding?

I guess you have never worked for a large company!

A lot of companies use Open Source software, the idea that software is worthless unless you pay a hefty license fee is frankly naive and outdated.

As for open source projects "targeting" markets, more silliness. Clearly you have no idea about Open Source, sales and markets are irrelevant.

It is strange and disappointing that people are so indoctrinated by corporate propaganda that says the "profit motive" is the only way to organise socitey, that they struggle to conceive of organisations that are not profit motivated.

[janoc]

I'm not sure what they're targeting. It's not clear from reading their website. VxWorks is mentioned on their website, so I assumed they were at least partially targeting VxWorks users, who are almost entirely commercial.

Can't really speak for the project, but VxWorks is mentioned in line with other things (such as POSIX) as something they are trying to implement features/APIs from, not necessarily as trying to compete with them. I think you have read too much into that statement.

It's all relative. It appears minimal to me. Perhaps people are becoming used to the open-source model of documentation (i.e. little to none) and don't find this an issue.

Sal, with all due respect, this is complete BS. Only a few months ago I have got a $3000 piece of commercial equipment in my hand where the entire "documentation" was a poorly translated Japanese PDF document explaining how to hack a Windows .inf file provided by Google, because the manufacturer couldn't be bothered to even ship their proper one. Not even an example application or some actually working demo was shipped with it. The manufacturer is a $6.2 Billion company, btw.

And this is by far not an exceptional case.  We have several other pieces of equipment in the $10-20k range at the office and software that is on annual subscription which is barely better than that.

Have you seen documentation for something like Unity3d or Unreal Engine? Those are big buck commercial 3D engines used by many of the "AAA" video games these days. The documentation is a bunch of tutorials mostly for the artists, API reference and a (self-help) forum. Unreal doesn't even have a complete API reference (not even autogenerated Doxygen-style), actually - use the source, Luke! A lot of open source projects have much better documentation than that.

So I am glad for you that you live in some wonderful world where perfect and complete documentation is standard, but the rest of us is not so fortunate. So stop knocking a project only because you have beef with open source for some reason.

[Sal Ammoniac]

I guess you have never worked for a large company!

I've worked for companies with from 12 to 100,000 employees, so I'd say that I have worked for a large company.

A lot of companies use Open Source software, the idea that software is worthless unless you pay a hefty license fee is frankly naive and outdated.

I never said that OSS is worthless. The primary issues I've had with OSS over the years is documentation and support. Most (but by no means all) examples of OSS that I've seen have poor documentation and marginal support. In a commercial environment, with tight deadlines, you need good documentation and support. If I could find an OSS project that did have good documentation and support, then I wouldn't hesitate to use it in a commercial environment. But if I have a problem and I need immediate support, I don't want to have to post a question to a forum and hope to get a quick response. I want to call someone on the phone and get immediate support. Not all commercial software offers this either, and I choose not to use it.

It is strange and disappointing that people are so indoctrinated by corporate propaganda that says the "profit motive" is the only way to organise socitey, that they struggle to conceive of organisations that are not profit motivated.

That's not my view. I'm more pragmatic. I choose software that fulfills my needs, and good documentation and support are two very important criteria, regardless of whether it's commercial software or OSS. In my experience, I've been disappointed by OSS too often to blindly choose it without thorough research just because it's free.

[Sal Ammoniac]

Sal, with all due respect, this is complete BS. Only a few months ago I have got a $3000 piece of commercial equipment in my hand where the entire "documentation" was a poorly translated Japanese PDF document explaining how to hack a Windows .inf file provided by Google, because the manufacturer couldn't be bothered to even ship their proper one. Not even an example application or some actually working demo was shipped with it. The manufacturer is a $6.2 Billion company, btw.

Sounds to me like you need to do better research before buying expensive equipment. Just because you can offer commercial counter examples of products that have poor documentation doesn't imply anything about open-source products.

There are tens of thousands of OSS projects out there. The vast majority of them have poor or nonexistent documentation. Sure, there are examples of OSS with excellent documentation (e.g. Linux), but the majority do not.

[ruffy91]

There are tens of thousands of OSS projects out there. The vast majority of them have poor or nonexistent documentation. Sure, there are examples of OSS with excellent documentation (e.g. Linux), but the majority do not.

IMHO Linux is very poorly documented.
I occassionally write a kernel mode driver and I find it easier to use the source as reference than the documentation (which is mostly just autogenerated from source). Not to get started with most 3rd party libraries.

I think from the documentation point of view NuttX seems to be at least on the same level if not better.

[amspire]

the idea that software is worthless unless you pay a hefty license fee is frankly naive and outdated.

well …  of course you can believe whatever you want to believe

Have to agree with donotdespisethesnake here. If you look at the key people in many open source projects, they are often employees of big companies and the companies are paying them to be involved in the open source project. Rather then having an external company that has experts in the software, they have their own staff who are experts and those staff can freely talk to all the other experts in that software as they are in regular contact anyway. They can push the development of the open source software in the directions the company needs. There is nothing more frustrating then a closed source licensed solution that almost does exactly what you need.

[rob77]

it's far far from linux so even quoted "linux" in the topic is extremely incorrect, but actually it looks really good ! i like it and i will definitely give it a try in one of my projects i like the POSIX compatibility, BSD sockets, memory management, wide variety of supported micros and hardware... and actually it has a very good documentation on porting, so porting to other (or slightly different) micros is not a big problem. i have a small project currently in planning/design phase with ATSAM3S, so definitely will give it a try.

[Marco]

can I also say that VxWorks can be used in Avionics under DO178B level A whereas linux is rejected ?

Windows isn't certified either. Cause it would be silly. You'd just have some real time kernel underneath with real time drivers, with a desktop OS on top as a ridiculously overweight GUI library.

uC/OS-II which is restrictively licensed open source is though.

[Marco]

I was trying to make the comparison with Linux (ie. a huge desktop OS with decades of backward compatible codepaths shitting up the code tree). So I wasn't referring to Windows CE.

Is there anything on the web about Windows based devices with DO-178B certification, or statements by Microsoft that they will supply evidence to help certify such devices, or is that all hidden behind NDAs?

[janoc]

Sounds to me like you need to do better research before buying expensive equipment. Just because you can offer commercial counter examples of products that have poor documentation doesn't imply anything about open-source products.

LOL. If those products are the only ones in their class on the market, you can do as much research as you want. It won't change a thing. We are not stupid, you know?

Buy any of the professional virtual reality equipment and you will see what you get. At best a pdf and a buggy Windows SDK, if that - a lot of very expensive equipment is sold without much of documentation, code or support at all. And you don't have choice, because there is simply nothing else on the market. For example, until OculusVR came along with their Oculus Rift, the only choice for a head mounted display was likely something from Sensics or Kaiser/Rockwell Collins starting at $20-40k. And all you would get was a box with the helmet and nothing else. Figure the rest out yourself! That's how it still works in this field, sadly.

So when I see you knocking an open source project because it doesn't have documentation up to your standard, I guess you haven't seen a lot yet.

There are tens of thousands of OSS projects out there. The vast majority of them have poor or nonexistent documentation. Sure, there are examples of OSS with excellent documentation (e.g. Linux), but the majority do not.

Yes, that's true. But my point is that poor documentation and bad/nonexistent support is hardly something that is unique to OSS world. You can say pretty much the same thing about commercial products - and there you don't even have the source code that you actually can look at if something doesn't work!

BTW, support for software is very overrated. It is good mostly to mollify the beancounters and managers that they know they can yell at some poor support/sales rep when there is a problem. However, from a practical point of view it is often worth little (not counting software updates/bugfixes that are often lumped under "support" these days). How often did you actually call your vendor because of a bug in your IDE or compiler? And did they actually fix it for you? We used to pay a lot of money for software support - and stopped, because it was useless. The support was so poor and incompetent, that in the end it didn't matter whether or not we had it. At least with open source code I can fix in the worst case myself or pay someone to do so.

Oh and I won't forget the "account manager" I had the "pleasure" to meet in one of my previous jobs - when we complained that their service is poor and we can often fix things faster ourselves than by having to deal with their horrid support, despite paying through the nose for next business day service, we were told that we needed to pay for "gold level support" if we wanted better service. Well, that guy's company lost out on about a half million business for a new building not long afterwards ...

[mac.6]

Given the price you pay for some it's a minimum to have good doc, and in some case it's arguable (try find some real doc on linux kernel integration into lauterbach).
Some product you mention are now dead (CW for example).

Back to nuttx, documentation is here but not very complete, it's clearly not for the beginner (several key steps are missing).
Not for typical embedded windows developer also as it's mainly a unix crossdev environment.
Build system is rather akward, as using buildroot for toolchain but not for OS itself, requiring external tools barely explained in the doc.
I didn't check sources to see if they are at least doxygen'ed.

[Sal Ammoniac]

So when I see you knocking an open source project because it doesn't have documentation up to your standard, I guess you haven't seen a lot yet.

Then we're in two different industries apparently. The equipment we buy is expensive, yes, but it is very well documented and has excellent support. If we have any issues we call the support people and we get help fast. That even includes loaner equipment when we need it, no questions asked (because they value our business and know we can go to one of their competitors).

How often did you actually call your vendor because of a bug in your IDE or compiler? And did they actually fix it for you? We used to pay a lot of money for software support - and stopped, because it was useless. The support was so poor and incompetent, that in the end it didn't matter whether or not we had it. At least with open source code I can fix in the worst case myself or pay someone to do so.

Several times in the past year. They were able to reproduce the bugs and we usually had a new version to try before the end of the week with fixes for the issues we reported.

Let's say we had used GCC instead--who would we call to report a bug? Richard Stallman? And how long would it take to get the bug fixed? Sure, GCC is open source, but have you ever looked at the code? It takes a real compiler guru to make heads or tails of it and our embedded engineers wouldn't have a clue as to how to fix a problem in that morass.

[janoc]

Then we're in two different industries apparently. The equipment we buy is expensive, yes, but it is very well documented and has excellent support. If we have any issues we call the support people and we get help fast. That even includes loaner equipment when we need it, no questions asked (because they value our business and know we can go to one of their competitors).

Then I am positively envious - in our field this is not at all common. Lot of gear is sold with the tacit understanding that you are getting esentially something that maybe 10 other people in the world have and apart from a gross malfunction/breakage you are on your own. Virtual reality used to be a seriously niche industry - where else could you sell literally the same piece of crappy gear for 20 years for the same price, only adding an RS232 to USB converter when the serial ports went the way of the dodo?

Several times in the past year. They were able to reproduce the bugs and we usually had a new version to try before the end of the week with fixes for the issues we reported.

Again, very lucky - we have reported bugs on our expensive motion tracking system and they are still not fixed. But at least a lot of yelling got us a free upgrade to a new version of the software - with more bugs.

Let's say we had used GCC instead--who would we call to report a bug? Richard Stallman? And how long would it take to get the bug fixed? Sure, GCC is open source, but have you ever looked at the code? It takes a real compiler guru to make heads or tails of it and our embedded engineers wouldn't have a clue as to how to fix a problem in that morass.

Why would you want to report bugs to Stallman? Open source/free software != abandonware (even though some companies release their stuff like that). That there isn't a customer support rep you can call doesn't mean the software is unsupported.

GCC Bugzilla:
https://gcc.gnu.org/bugzilla/

Bug reporting instructions (including how to produce repro cases, what are not bugs, common issues, etc.):
https://gcc.gnu.org/bugs/

Fixing time - I haven't found statistics about average times, but some randomly picked, recently fixed bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748 (3 days)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77768 (1 day)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77802 (4 days)

The time is between the bug was reported and the last update of the bug entry - so it could have been actually fixed quicker than that, because the update date includes even things like people commenting on the bug and various administrative actions (like status changes, assigning developers, etc.).

I am sure there are some that sit there much longer, but the project is pretty responsive overall. You get the fix in the next maintenance release which are 2-3x a year. If you need it faster, you can either download a snapshot or compile your own patched version of GCC with the fix in it, which is not that hard, actually. I have built both Intel Linux toolchain and also bare metal ARM and AVR ones, no big deal, especially now when there are tools around fully automating this.

Re GCC being a morass - yes, fully agreed. However, it is both a huge project and also has a lot of history, so the level of "morassness" is not out of the line with other projects of comparable size and complexity. If I don't have to I am certainly not going to dig into it, though.

However, the ability to download the source and patch in a fix myself has saved my bacon a few times already. That is something I cannot do with e.g. Microsoft's Visual C++ when it dumps an internal error on me or compiles something wrong - had that recently with VS 2015. If it is a genuine bug, Microsoft will fix it, but then you may have to wait 6 months or more until the next Visual Studio update to get it (we don't have access to betas and pre-releases - and those often have their own share of issues).

Another such case I have is Nvidia's CUDA toolkit - it doesn't support the latest Visual C++, so I am stuck with some projects until Nvidia wakes up and updates their hardwired version check, despite VS 2015 being out for over a year now. If I had the source, I could at least try to fix that check. Or pay a 3rd-party to do it for me if really desperate. Right now I am at the mercy of the vendor, though - we are not large enough company to warrant the kind of special attention big game development studio or someone like Oculus gets from them.

[free_electron]

pfff. it cant even run on an 8051. -FAIL-

[rob77]

pfff. it cant even run on an 8051. -FAIL-

probably because gcc doesn't support 8051 ?

[janoc]

and also bare metal ARM and AVR ones, no big deal
especially now when there are tools around fully automating this.

and AVR is handled by Atmel, not directly by GNU
and it happens that compiling their patched-gcc
is even a nightmare for automatic builders

Not sure where do you have this from, AVR is a normal supported backend in GCC, included in the standard distribution.
https://gcc.gnu.org/backends.html

Atmel perhaps has their own version supporting more chips or is contributing patches to GNU, that is possible, because they use it with their own tooling (AVRStudio). But you can certainly  build a working AVR toolchain directly from the official sources - I have done it several times.

If you want to build your own, the instructions are here:
http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_GCC_Toolchain#Build_from_Sources

Also http://crosstool-ng.org/ can apparently build AVR toolchain. That I haven't tried, I have used it only for ARM toolchain once.

[janoc]

pfff. it cant even run on an 8051. -FAIL-

probably because gcc doesn't support 8051 ?

Well, it did support 8051 using the SDCC compiler before, but they obsoleted it:
https://github.com/jodersky/nuttx/commit/9ee5cfaffa313949563fb37f7cd39a2b7620a4dd

However, trying to run Nuttx on '51 is like trying to bolt an F1 engine onto a Trabant ...

[free_electron]

pfff. it cant even run on an 8051. -FAIL-

probably because gcc doesn't support 8051 ?

ah yes. GCC ... short for  'great crap compiler'...

anyway 8051 doesn't need RTOS. it has 4 banks and partitioning. use one bank for a microvisor and you can run three threads without risk of ever getting clashes.

[andyturk]

ah yes. GCC ... short for  'great crap compiler'...

Some of us quite like GCC. 

[Sal Ammoniac]

I prefer Clang/LLVM.

[rob77]

ah yes. GCC ... short for  'great crap compiler'...

Some of us like GCC. 

and some hate it

you would be surprised how much stuff wouldn't exist without GCC

[mark03]

ah yes. GCC ... short for  'great crap compiler'...

Some of us like GCC. 

and some hate it

you would be surprised how much stuff wouldn't exist without GCC

Linux for example.

[janoc]

Atmel perhaps has their own version

the question is not IF you can(1), the question is how good it is, and how fast GNU updates its AVR repository
in the specific case it took 2 years to have a working >64Kbyte, and the GCC repository took other 4 months
to be synched to the Atmel's one

They update the repo as fast as they get the patches I suppose. There is a separate group maintaining the AVR port, but I have no idea what their relationship (and consequently relationship with Atmel) is. On the other hand, AVR is an architecture requiring quite a few hacks - and the vendors often simply don't bother to do the modifications properly, only taking the cheapest way out to scratch their immediate itch. So the patch doesn't get accepted by the upstream maintainers. Then you get issues with patches that don't work, things that need to be tweaked or hacked, etc. before the code builds. However, that probably shouldn't be blamed at GCC developers!

corollary: about AVR8, Atmel's repository is more updated than GCC's one, you should know that

anyhow, dude, I was there when it happened and I switched to Keil definitively for that specific reason!

Yes, I know, but my point was that you don't need to go to Atmel to build their (poorly patched) gcc if you need it for AVR, not to enter into a pissing contest which version is more up to date. Granted, you may not have the latest features and/or chip support if you build from the official repository.

edit:
(1) it's said "if you have infinite time you can obviously always have the time to do everything"
and here we go, too often the manual usually says something like ./configure --black magic && make
which is  … definitively  NOT enough and subjected to swift obsolescence (their documentation ... )
not mentioning that the gcc build-up is itself over-complex if compared to e.g. LLVM? LLC?
anyhow, with everything made by GNU you always need *A LOT* of manual tuning

You are masivelly exaggerating the issue. Yes, you need to know what you are doing and the automake/autoconf build system isn't the most user friendly thing in the world, especially if you happen to build in Windows (where it can be outright pain). However, the build is fairly well documented and no, doesn't change that often as to make the documentation instantly obsolete. Not sure where did you get that from.

Comparing to LLVM is not really fair - how many architectures and backends and front ends does the LLVM support? And how many does GCC? Also LLVM has the advantage that it is much younger (13 years vs 30), doesn't need to maintain compatibility with obscure platforms and can use more modern tools.

p.s.
even CrossDev (an automatic cross-compiler builder, made by gentoo) has issues with gcc
and it usually takes three of four times before turning its config flags into success 

I think that is more a statement about CrossDev than anything about GCC ...

I am really surprised how are people so quick to bash GCC and GNU project - when most of the ARM, AVR, PIC, Linux and Unix toolchains are GCC/GNU based and without them we would be still paying through the nose for tooling. Just look at the prices of Keil/IAR or Intel compiler suites.

Why don't companies invest into their proper tools when this ecosystem is so horrible? Ah right, it would actually cost money ... Also the ones actually switching to LLVM/Clang (Apple, Android from the major ones) are doing it mainly for licensing reasons and not because of the better performance/quality of the compiler - you can add proprietary binary-only extensions to LLVM, you can't do it for GCC. (LLVM/Clang generates about equivalent or little slower code than GCC, but the diagnostics are nicer).

[Sal Ammoniac]

Comparing to LLVM is not really fair - how many architectures and backends and front ends does the LLVM support? And how many does GCC? Also LLVM has the advantage that it is much younger (13 years vs 30), doesn't need to maintain compatibility with obscure platforms and can use more modern tools.

That's part of the problem. How many people still use GCC to compile code for a PDP-11, a VAX, or an Intel i960? Ditto for some of the front ends. Having to maintain compatibility with all of these ancient and obsolete architectures is one of the things holding GCC back. Sometimes a clean slate approach is needed to sweep away all of the musty cobwebs of accumulated history.

[Marco]

LLVM/clang was offered for GCC-next, but political problems and lingering opposition to stored intermediate representations prevented it from happening. Unfortunate for the open source movement.

Not sure if the Apple sponsorship really helped the project all that much.

[janoc]

That's part of the problem. How many people still use GCC to compile code for a PDP-11, a VAX, or an Intel i960? Ditto for some of the front ends. Having to maintain compatibility with all of these ancient and obsolete architectures is one of the things holding GCC back. Sometimes a clean slate approach is needed to sweep away all of the musty cobwebs of accumulated history.

I don't see how maintaing support  for a PDP-11 or a VAX affects things like a build system or latest C++ support.  GCC is very modular, so support for different architectures is mostly a matter of someone keeping the code generating back end alive. It has negligible impact on other things.

It is a manpower issue - which is why old and disused architectures get periodically deprecated and removed if there isn't anyone maintaining them. And it is also an issue that GCC is often the only compiler in town for many of those older, but still used platforms, especially if you want a semi-reasonable compiler. 

One of the first things people did whenever deploying a commercial Unix (SCO, SunOS, Solaris, Ultrix, IRIX, AIX, to mention only those I had to deal with in the past) used to be downloading GCC, GNU make and all the other related tools. The vendor toolchains were expensive, frequently not even shipped with the OS and incredibly crappy, stuck with ancient C/C++ standards (like K&R C in early 2000s)

So if you wanted to install current versions of a lot of software, either because you needed some feature or because the vendor supported one had still unfixed security holes from 20 years ago, you had to use GCC, the vendor's compiler wouldn't have worked. These may sound like obscure platforms today, but those machines are still widely used.

Throwing everything away and starting from scratch is often simply not an option, especially on a project of this size. The manpower that would be required to rewrite the compiler and the accompanying suite of tools from scratch simply isn't there, because it would have to happen in parallel while supporting the existing codebase which people use. And nobody would pay the developers for that neither.

If you really want to find a fault on GCC, then it is politics. That is one of the reasons why the LLVM has been started, because the GPL license behind GCC and the requirement for copyright assignment to FSF are not up to everyone's taste, especially vendors who want proprietary mods. LLVM has no such issues, for good or bad.

[legacy]

One of the first things people did whenever deploying a commercial Unix (SCO, SunOS, Solaris, Ultrix, IRIX, AIX, … ) used to be downloading GCC, GNU make and all the other related tools. The vendor toolchains were expensive, frequently not even shipped with the OS and incredibly crappy, stuck with ancient C/C++ standards (like K&R C in early 2000s)

that's bullshit, I am an IRIX user since 2001
MIPS/Pro is far away from the definition of "incredibly crappy"
on the contrary those gnu things they have always disapointed
so much that every IRIX user with some money has tried
to get a copy of the MIPS/pro on ebay as soon as possible

I got my copy for 150 USD, original full set of v7.3
it comes with a personal license

performances and the quality of the assembly are superlative

[legacy]

gcc-arm on RiscOS vs Acorn-SDK/DDE ?

I happen to have a RiscPC/700, 2x32Mbyte of ram, StrongArm@200Mhz
loaded with RISC OS Adjust v4.39, gcc v4.1.2, and DDE-2016
and I can confirm you that

• gcc, eats more ram, much more ram, RiscPC machines are limited to 64M-128Mbyte
• the generated assembly by gcc is less optimized, resulting a slower execution of binaries
• the build up time with gcc and gnu make is slower than DDE by 10 orders of magnitude
• gdb is inferior to their adb debugger, gdb takes longer in debugging activities
• all the GNU documentation is less useful, DDE comes with exhaustive and concise doc and examples

their DDE toolchain costs just 60 UKP (if you have a RPI you will have a discount)

[newbrain]

• the build up time with gcc and gnu make is slower than DDE by 10 orders of magnitude

You really must have a lot of time on your hands, to test this...

[Marco]

If you really want to find a fault on GCC, then it is politics.

Sure, but more in the sense of people getting territorial about their own code and seeing their commit privileges as proof their shit doesn't stink while everyone else's shit needs a couple years to mature with a lot of ass kissing before it's deemed worthy of being included.

That is one of the reasons why the LLVM has been started, because the GPL license behind GCC and the requirement for copyright assignment to FSF are not up to everyone's taste, especially vendors who want proprietary mods. LLVM has no such issues, for good or bad.

It might not be to everyone's taste, but Chris Lattner didn't have strong feelings about that. As I said, it was offered for a new generation of GCC. He was pretty sure most of the other contributors could be convinced as well.

[rob77]

@Legacy - you start to be boring and your posts are being stupid....

stop comparing a single purpose compiler highly optimized for ARM processors with a compiler which supports most of the mainstream architectures and is design to compile virtually anything for any platform.
it's like comparing the top speed of a race car optimized for racing only on race tracks  with a minivan which is supposed to be used in many roles in real life.

p.s. if your compiling is crashing with a stable release of GCC everyone else is using , then it means you should really think about yourself

[legacy]

@Legacy - you start to be boring and your posts are being stupid....

in fact:

stop comparing a single purpose compiler highly optimized for ARM processors
with a compiler which supports most of the mainstream architectures and is design
to compile virtually anything for any platform

oh, so, gcc is "designed to compile virtually anything for any platform"
and … should we all have an orgasm for that ?

dude, we need a compiler to compile with the less effort

that's exactly what I don't like: bullshit over the whole line
e.g. gcc on Irix, I am 100% sure you have never used MIPS/pro
but wait … we can compare with gcc because MIPS/pro is super optimized for MIPS
whereas GCC is designed to put its bits and bytes
virtually anything on any platform, even on toasters

with fanatics it's always a boring waste of time

[rob77]

with fanatics it's always a boring waste of time

couldn't agree more with that statement...  

now look at this thread and see who is fanatically glorifying DDE over GCC ignoring the fact he's comparing apples with oranges.

EDIT: @ Legacy and also you deleted your post i was replying to... unfortunately i was not quoting you... it show what kind of person are you. Sir you earned the very first place in my ignore list which was empty till now.

[free_electron]

stop comparing a single purpose compiler highly optimized for ARM processors with a compiler which supports most of the mainstream architectures and is design to

and what is today's mainstream embedded architecture ? ARM ! everything else is dead, croaking or being carried out the backdoor to shoot it. i am willing to stat that ARM has at least 60% of the 32 bit embedded market. seconded by some MIPS machines. and that's it. the rest is poppycock.

as for 8 and 16 bitters : those are dying out very fast. Look at what is being introduced in the market these days. its all Cortex based. Every single new micrcontroller being released is Cortex. Even Atmel has Cortex machines now. Only Microchip is stuck to MIPS (actually that was the reason they bought atmel : to get their hands on an ARM portfolio .. )

[rob77]

stop comparing a single purpose compiler highly optimized for ARM processors with a compiler which supports most of the mainstream architectures and is design to

and what is today's mainstream embedded architecture ? ARM ! everything else is dead, croaking or being carried out the backdoor to shoot it. i am willing to stat that ARM has at least 60% of the 32 bit embedded market. seconded by some MIPS machines. and that's it. the rest is poppycock.

as for 8 and 16 bitters : those are dying out very fast. Look at what is being introduced in the market these days. its all Cortex based. Every single new micrcontroller being released is Cortex. Even Atmel has Cortex machines now. Only Microchip is stuck to MIPS (actually that was the reason they bought atmel : to get their hands on an ARM portfolio .. )

fully agree with you !

but legacy's overly glorified DDE is not a compiller for embeded ARM systems you mention... basically the DDE is a toolchain including compiler for RISC OS made by Acorn.   so saying it's superior to GCC is bullshit. it's comparing apples with oranges...
considering the facts theat DDE is not even listed here : https://en.wikipedia.org/wiki/List_of_ARM_Cortex-M_development_tools
it seems it's not even usable for embeded systems (while GCC is)

i'm not saying GCC is the best compiler , i'm saying it's a good compiler and many useful projects wouldn't exist without it.

[janoc]

that's bullshit, I am an IRIX user since 2001
MIPS/Pro is far away from the definition of "incredibly crappy"
on the contrary those gnu things they have always disapointed
so much that every IRIX user with some money has tried
to get a copy of the MIPS/pro on ebay as soon as possible
...
performances and the quality of the assembly are superlative

And when was your MIPS/pro last updated for current C/C++ standard?

Assembly quality is of little use when the code won't compile because the compiler doesn't support the new features.

[janoc]

stop comparing a single purpose compiler highly optimized for ARM processors with a compiler which supports most of the mainstream architectures and is design to

and what is today's mainstream embedded architecture ? ARM ! everything else is dead, croaking or being carried out the backdoor to shoot it. i am willing to stat that ARM has at least 60% of the 32 bit embedded market. seconded by some MIPS machines. and that's it. the rest is poppycock.

as for 8 and 16 bitters : those are dying out very fast. Look at what is being introduced in the market these days. its all Cortex based. Every single new micrcontroller being released is Cortex. Even Atmel has Cortex machines now. Only Microchip is stuck to MIPS (actually that was the reason they bought atmel : to get their hands on an ARM portfolio .. )

fully agree with you !

but legacy's overly glorified DDE is not a compiller for embeded ARM systems you mention... basically the DDE is a toolchain including compiler for RISC OS made by Acorn.   so saying it's superior to GCC is bullshit. it's comparing apples with oranges...
considering the facts theat DDE is not even listed here : https://en.wikipedia.org/wiki/List_of_ARM_Cortex-M_development_tools
it seems it's not even usable for embeded systems (while GCC is)

i'm not saying GCC is the best compiler , i'm saying it's a good compiler and many useful projects wouldn't exist without it.

Folks, world isn't just embedded MCUs. GCC wasn't even originally targetting that space. So while ARM is prevalent in the embedded space, there are still plenty of other mainstream applications where a compiler is needed and which are not ARM-based (and likely won't be for a while yet). Like that PC you are most likely writing your embedded code on ...

[legacy]

I was comparing gcc/RISCOS with DDE/RISCOS:
the DDE is superior, it generates better code, more optimized,
better documented, suited with a better debugger
and it's much more faster and comfortable (more productivity)

which IS the first and most important thing
you should look at, instead of that bullshit
on "gcc virtually supports anything including dead dinos
(PDP11 ? who cares?) and toasters" 

supporting and promoting all of those legacy in GCC implies
a LOT of complexity in the source code, and a lot of effort
aka human power 

also it makes difficult to re-target the compiler for other purposes
e.g. the dude of the Magic1 HomeBrewCpu project
(he happens to have a job in google, he is not the last moron on the Earth)
used LCC instead of gcc because gcc is TOO much complex



concerning MIPS/Pro on IRIX
although you can still buy your copy through dealers
not mentioning through ebay, anyhow, just for the record
MIPS/pro came in its EOL (end of life) since 2005,
and since then it's considered abandonware

dead? yes, it's gone, and it was not the point,
since when MIPS/pro was introduced and used,
before 2005, gcc had always sucked (and it still sucks) a lot!

doesn't MIPS/Pro support C++11? No, it doesn't,
and we have to use gcc(1)
if we want to compile modern things on IRIX
(if it makes sense, sometimes it does not),
oh, things said without knowing what the frog
you are talking about, in fact, still worse in the top list
the above fanatic guy said that
all the compilers for every UNIX (so, including IRIX)
were "incredibly buggy and crappy", which is proved to be a lie

but we love to tell bullshit because we love GNU, ain't it?

basically the DDE is a toolchain including compiler for RISC OS made by Acorn.   so saying it's superior to GCC is bullshit. it's comparing apples with oranges

can't you re-target the whole DDE-toolchain
(which is script-able through parameters,
therefore you can exclude the default crt0,
link you own c-run-time, your own libraries
and use your own linker script,
and your own CFLAGS etc etc etc
forcing the compiler to exclude OS-headers)
for your own bare metal profiles?

no, obviously you can't because it's not GCC



(1) waiting for a complete switch to LLVM,
currently we (IRIX users) don't have enough
man-power to achieve such a goal



edit:
last time I open this topic

[janoc]

I was comparing gcc/RISCOS with DDE/RISCOS:
the DDE is superior, it generates better code, more optimized,
better documented, suited with a better debugger
and it's much more faster and comfortable (more productivity)

which IS the first and most important thing
you should look at, instead of that bullshit
on "gcc virtually supports anything including dead dinos
(PDP11 ? who cares?) and toasters" 

And you go on to generalize from that over the entire compiler suite. Did it occur to you that maybe, just maybe, the problem is that the GCC backend for RISCOS was crappy for whatever reason? Which is neither an exception (there are many poorly supported architectures like that, especially old and obscure stuff) nor has any bearing on the quality of the other backends or the language frontends.

dead? yes, it's gone, and it was not the point,
since when MIPS/pro was introduced and used,
before 2005, gcc had always sucked (and it still sucks) a lot!

Um right. Except pretty much every single software I had to deploy on our Indigos, Octanes, O2 and the big iron Onyx during 2001-2005 required gcc to build for whatever reason ... 

If the software doesn't build with your compiler without extensive hacks or porting, the debate about MIPS/Pro being superior is at best academic. I needed to deploy a patched sendmail/postfix/whatever *now* or risk the machine getting hacked and not try to figure out how to make the build work with another, unsuported, compiler to gain a bit of compilation speed or runtime performance.

oh, things said without knowing what the frog
you are talking about, in fact, still worse in the top list
the above fanatic guy said that
all the compilers for every UNIX (so, including IRIX)
were "incredibly buggy and crappy", which is proved to be a lie

Considering I have personally used and had to support all those systems listed for living (and a few I didn't list). I think I know a wee bit what am I talking about. You have only declared it a lie and called me a fanatic - with no supporting argument.

but we love to tell bullshit because we love GNU, ain't it?