Hacker News Reader

Comment by ericseppanen | Hacker News Reader

For those who haven't had the pleasure: developing on Tensilica Xtensa cores generally means living within 128-256KB of directly-accessible memory; a windowed register file that makes writing your own exception handlers "interesting"; a 6-year-old GCC bolted to a proprietary backend; per-seat licensing fees to use the compiler; and a corporate owner that's only halfway interested in the ecosystem they now control.

So yeah, kind of wishing it would just die and let ARM take over the embedded space.

View on HN

I'm not personally opposed to Tensilica "dying", especially if it doesn't involve Cadence dying, since they are a (somewhat indirect) competitor from my point of view, but ARM is not a substitute for Tensilica. You can't extend its ISA unless you license the arhictecture for $30M. A DSP like Tensilica's is also much more efficient than ARM on a range of tasks, and in particular, having local memory instead of caches is done for a reason. (The least efficient accelerator of all and the favorite of academics who have easy access to it, GPUs, also have this.)

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.

The least efficient accelerator of all ... GPUs

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?

In terms of performance/power or per dollar, GPUs are only good at graphics - if you're doing deep learning, for instance, GPGPU will lose to almost any other accelerator, Google's TPU is one example, FPGAs are another, a DSP designed for deep learning by CEVA, Tensilica or Synopsys are a third, and by "lose" I mean factors of 5-10x at least, assuming the same process node and operating environment, especially when deploying networks as opposed to training them. But deep learning is just one example, it'll be the same story elsewhere. The strength of GPGPU is high availability and a relatively simple & convenient programming model relatively to other accelerators.

Cadence is an EDA company. They have a lot of other software they sell.

Precisely, and I use it, so wouldn't want Tensilica to die as a part of Cadence dying.

Ceva DSP is almost same story about compiler. They used to have GCC2.95 glued to their proprietary backend, 33% of compilations results in crash :-). They got better by going to GCC4.4, but still use crazy licensing. But other DSP cores are often even worse offering as little as only assembler.

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

> 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?

Hardware companies treat SW as crap usually

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

> a 6-year-old GCC bolted to a proprietary backend

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.

From what I can tell, they have structured it in a way that it's a violation in spirit, but not in letter.

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.

Yeah they tried to obfuscate their internals precisely so this wouldn't happen. Notice how it didn't stop anybody, but instead led to poor user experience.

Typically those are creative workarounds for the GPL not actual violations.

The question of whether what they've produced is a derivative work of GCC is one for the courts, which tend to take a dim view of creative workarounds.

Absolutely not. The GPL boundary is very clearly defined and intentionally has never been brought to court.

"The broadest and most established definition of derivative work for software is the abstraction, filtration, and comparison test (“the AFC test”) as created and developed by the Second Circuit. Some circuits, including the Ninth Circuit and the First Circuit, have either adopted narrower versions of the AFC test or have expressly rejected the AFC test in favor of a narrower standard. Further, several other circuits have yet to adopt any definition of derivative work for software.

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

How so? The GPL grants permission to distribute derivative works in general under the GPL, and additionally to distribute derivative works consisting of object code that is the compiled form of system libraries (narrowly defined) without including that source (though AIUI still under the GPL); that's all. If someone were distributing a derivative work of a GPLed program not under the GPL and therefore without permission (i.e. without being otherwise licensed by the copyright holder), that would be copyright infringement. The question of what is or is not a derivative work in the general case is absolutely a question for the court. The FSF explicitly says as much: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

All of this is irrelevant. The GPL stops at the process boundary and that's exactly what these compilers do. They provide the modifications to GCC itself under the GPL and then have separate executables that are proprietary that feed things in and out of GCC.

It's still pretty clearly a violation of the intentions of the gcc developers, and something that only exists to wrap one product seems very suspiciously like a derivative work. I'd be curious to see this tested in court.

But the FSF would not be curious to test this in court because they know they lose. I had this conversation many years ago with people that wrote extactly this type of software and the general consensus was that the FSF would stay away from probing the GPL there because there is angood chance that the ruling would set a precedent they don't want. The FUD surrounding the license in that regard is preferrable.

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.

The text of the GPL (nor the FSF FAQ) does not explicitly support the "stops at process boundaries" interpretation, though a form of that's been a popular interpretation since at least the GPLv2 period.

> The GPL stops at the process boundary

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.

What the FSF wants the boundary of the GPL is irrelevant, since copyright law of the televant jurisdiction determines whether copyright license is even necessary, and the boundary of derivative works in copyright is both often unclear (as noted in sibling comments, different circuits in the US apply different tests that have not been harmonized by the Supreme Court) and differ between jurisdictions.

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

That's the company/family powering the ESP8266 SoC isn't it ( LX106)? Is it just their DSP chips that are using that weird gcc/proprietary frankenstein? I ask because I have an xtensa lx106 cross-compiler for the esp8266 chip installed which appears to be GCC 4.8.2

The ESP8266 community has their own, community-developed GCC port for the LX106 that they use. It was one of the reasons that it took so long for there to be a practical way to run your own code on it. I believe it was based on an existing out-of-tree port for one of the other not-quite-compatible chips in the family.

I'd be interested in running Rust on the ESP8266 - are you aware of any efforts of getting LLVM to work on the LX106?

the C backend to LLVM was the most promising way to get Rust on a lot of embedded devices, sadly, it has stalled.

Yeah it is. Maybe there is something about the Tensilica cores, as the ESP8266 still hasn't got a real contender? Apparently they have a special toolchain that lets customers create customized cores in a more or less automated way, and they started as a dataplane/DSP company in the 90s. Quite weird.

Not sure what the competition looks like. I saw this the other day but I haven't read much more about it: http://hackaday.com/2016/07/28/new-chip-alert-rtl8710-a-chea...

True, that one looked ok, but 48k of RAM is a step down, and I don't see any other peripherals (e.g. bluetooth) that would make me want to switch.

The first real contender to the ESP8266 is set to release September 1st: the successor to the ESP8266, the ESP32 - now with dual Tensilica cores (and a bunch of other stuff).

I'm waiting for this one to drop like a little girl for a pony on christmas. Hope its not gonna be a disappointment for some reason.

That sounds like a violation of the GPL or at least some sort of trickery.

Isn't that par for the course for DSPs? Now-a-days I see a lot of hybrid DSPs with ARM cores that you can run whatever gcc you want on them but the main processing cores that do all that DSP goodness usually require some proprietary software from the vendor to operate.

How does the esp8266 SDK get round this. They're using an Xtensa core but make the SDK freely available (it's horrible, but it's free).

there is a community driven fork of crosstools-ng which in turn is based on a gcc fork made by a tensilica/cadence employee (jcmvbkbc). both gcc and gdb are ported to the call0 calling convention (no register windows on lx106).

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

That was my thought too. I guess it worked well for them, but it certainly wouldn't be my first choice. I wonder what the 10 custom instructions were?

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've been involved in design of an ASIC that used a customized Tensilica DSP, circa 2009. The custom instructions were the main reason we opted for that core. There are a ton of other customizations that you can make with Tensilica so you end up with a core that meets 100% of your needs with very little fluff -- almost as if you rolled your own.

I do wish ARM would get in on that action.

Radeon R600 (HD 2000/3000 series) also used xtensa as an embedded controller and Unified Video Decoder

The "add your own instructions" thing is a pretty cool, no doubt. I would be surprised if most ASIC designs really really need the low latency that provides, especially considering the other costs involved in adopting a minor-league ISA.

They do... the Cortex A/M coprocessor scheme can be used to add instructions & functionality IIRC.

Would there be any benefits from newer GCC on such specific and simple (compared to general-purpose CPUs) hardware?

- Fixes for compiler bugs; probably not that likely, but I'm used to knowing that on a free toolchain I can always try a newer version to see if it exhibits the same behavior. Being locked to an old version feels risky.

- 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.

Error messages, for one.

Reply on news.ycombinator.com