As to their compiler licensing - that's what happens when you develop for a small niche, you get more expensive tools which are worse than the free ones used by the majority. But it doesn't mean that the thing doesn't have its uses. I hear that a recent chip by AMD had 40 Tensilica (smallish, inaccessible to most software) cores.

The same is true about CEVA (which was mentioned in a sister thread), more or less.

Interesting, could you please elaborate on why you think this? Any data you know of on the subject? What are better alternatives in you view?

But, DSP core itself is nice, very well thought out in contrary to mainstream DSPs from TI or Freescale(now NXP).

Could you please elaborate on this statement?

The ones that manage to get software end up better in the long run

But I suppose in the case of MS they will have lower level information to make MS compilers target it directly without intermediaries

Not only a violation of the GPL, but for a code owned by the FSF and even Stallman himself.

That's a bold move. And very douchey.

They don't link to GCC code directly; instead they output the intermediate representation and execute a standalone binary to finish processing the IR. They offer source code for all their GCC modifications, but carefully work around the GPL to accomplish the same thing.

As an introductory matter, it is important to note that literal copying of a significant portion of source code is not always sufficient to establish that a second work is a derivative work of an original program. Conversely, a second work can be a derivative work of an original program even though absolutely no copying of the literal source code of the original program has been made. This is the case because copyright protection does not always extend to all portions of a program’s code, while, at the same time, it can extend beyond the literal code of a program to its non-literal aspects, such as its architecture, structure, sequence, organization, operational modules, and computer-user interface."

https://copyleft.org/guide/comprehensive-gpl-guidech5.html

In general it's 2016 and no longer relevant. The world moved on to LLVM and these GCC using toolchains are on their way out for good.

No it doesn't, and if it did that would only mean that processes that form derivative works of GPLed programs were unlicensed, and therefore a violation of copyright.

The GPL cannot create certainty that doesn't exist in the law on which the GPL relies to have any force.

it's quite a mess but it's getting better.

we (Cesanta) packaged and cleaned up the build environment: https://github.com/cesanta/mongoose-iot

you can use our docker based toolchain. It contains a few patches (malloc, stdio, moved all text sections to flash, ...), a gdb stub and serial crash dumper, working OTA solution and a sensible event driven networking API (based on the good old mongoose web server) for those that just can't wrap their heads around espcon .

please take a look. the embedded JavaScript interpreter thing can be disabled if not necessary

ARM licensed cores don't have an easy way to add instructions, but they do have the TCM bus which might be low latency enough, depending on what they were trying to do.

I do wish ARM would get in on that action.

- New language dialects (i.e. C++11). It's annoying to not be able to use the same techniques you use elsewhere because your ASIC core vendor made your compiler decision for you.

- New compiler features. It's no fun to have some clever trick I use other places fail to build because it depends on a compiler warning or some other GCC-ism that's present in all my other environments.

I also like to write unit tests and other simple mockups that can build and run on a plain linux machine, so it's nice to keep the delta between the two compilers as small as possible.