5 ms·

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 r

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.

ashitlerferad 10y ago
That sounds like a violation of the GPL or at least some sort of trickery.
aylons 10y ago
> 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.
- ericseppanen 10y ago
  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.
- frozenport 10y ago
  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.
- the_mitsuhiko 10y ago
  Typically those are creative workarounds for the GPL not actual violations.
  - lmm 10y ago
    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.
    - the_mitsuhiko 10y ago
      Absolutely not. The GPL boundary is very clearly defined and intentionally has never been brought to court.
      - lmm 10y ago
        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 https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
        the_mitsuhiko 10y ago
        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.
        nitrogen 10y ago
        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.
TD-Linux 10y ago
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.
- ericseppanen 10y ago
  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.
- bravo22 10y ago
  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.
  - rasz_pl 10y ago
    Radeon R600 (HD 2000/3000 series) also used xtensa as an embedded controller and Unified Video Decoder
- TickleSteve 10y ago
  They do... the Cortex A/M coprocessor scheme can be used to add instructions & functionality IIRC.
f00fc0d3 10y ago
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).
- mavera 10y ago
  > 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?
smcl 10y ago
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
- makomk 10y ago
  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.
  - MrBuddyCasino 10y ago
    I'd be interested in running Rust on the ESP8266 - are you aware of any efforts of getting LLVM to work on the LX106?
    - sitkack 10y ago
      the C backend to LLVM was the most promising way to get Rust on a lot of embedded devices, sadly, it has stalled.
    - deleted 10y ago
      [deleted]
- MrBuddyCasino 10y ago
  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.
  - smcl 10y ago
    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-cheaper-esp8266-competitor/ http://hackaday.com/2016/07/28/new-chip-alert-rtl8710-a-chea...
yosefk 10y ago
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.
- n00b101 10y ago
  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?
  - yosefk 10y ago
    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.
- samfisher83 10y ago
  Cadence is an EDA company. They have a lot of other software they sell.
ComodoHacker 10y ago
Would there be any benefits from newer GCC on such specific and simple (compared to general-purpose CPUs) hardware?
- startling 10y ago
  Error messages, for one.
- ericseppanen 10y ago
  - 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.
raverbashing 10y ago
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
new299 10y ago
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).
- ithkuil 10y ago
  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 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
chocolatebunny 10y ago
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.

ashitlerferad 10y ago

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

aylons 10y ago

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

ericseppanen 10y ago
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.
frozenport 10y ago
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.
the_mitsuhiko 10y ago
Typically those are creative workarounds for the GPL not actual violations.
- lmm 10y ago
  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.
  - the_mitsuhiko 10y ago
    Absolutely not. The GPL boundary is very clearly defined and intentionally has never been brought to court.
    - lmm 10y ago
      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 https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
      - the_mitsuhiko 10y ago
        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.
        nitrogen 10y ago
        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.

TD-Linux 10y ago

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.

ericseppanen 10y ago
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.
bravo22 10y ago
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.
- rasz_pl 10y ago
  Radeon R600 (HD 2000/3000 series) also used xtensa as an embedded controller and Unified Video Decoder
TickleSteve 10y ago
They do... the Cortex A/M coprocessor scheme can be used to add instructions & functionality IIRC.

f00fc0d3 10y ago

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

mavera 10y ago
> 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?

smcl 10y ago

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

makomk 10y ago
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.
- MrBuddyCasino 10y ago
  I'd be interested in running Rust on the ESP8266 - are you aware of any efforts of getting LLVM to work on the LX106?
  - sitkack 10y ago
    the C backend to LLVM was the most promising way to get Rust on a lot of embedded devices, sadly, it has stalled.
  - deleted 10y ago
    [deleted]
MrBuddyCasino 10y ago
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.
- smcl 10y ago
  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-cheaper-esp8266-competitor/ http://hackaday.com/2016/07/28/new-chip-alert-rtl8710-a-chea...

yosefk 10y ago

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.

n00b101 10y ago
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?
- yosefk 10y ago
  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.
samfisher83 10y ago
Cadence is an EDA company. They have a lot of other software they sell.

ComodoHacker 10y ago

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

startling 10y ago
Error messages, for one.
ericseppanen 10y ago
- 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.

raverbashing 10y ago

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

new299 10y ago

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

ithkuil 10y ago
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 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

chocolatebunny 10y ago

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.