Stuck at C: Programming languages unready for multicore

Embedded developers are slowly moving to multicore architectures, but they will make the transition without much help from parallel programming languages. A lack, and sometimes a plethora, of standards is also an impediment, said a panel of embedded software experts at the Power.org conference on Sept. 25.

"Eighty-five percent of all embedded developers use C or C++. Any other language is a non-starter," said David Kleidermacher, chief technology officer of Green Hills Software. "I don't have much hope a new parallel language will get a foothold," he added.

In the embedded space it took a long time to move from assembly language to C, and it was quite a struggle," said Tomas Evensen, chief technology officer of Wind River Systems. "So for the next 10 years in embedded there won't be a lot of new languages," he added.

Michel Genard, VP of marketing for Virtutech, agreed. "The apps moving to multicore will be existing apps, so C will likely be the implementation language," he said.

Embedded software developers will avoid the pain of moving to parallel languages by simply running at a high level separate programs or modules in parallel on multicore CPUs, he said. Such loosely coupled programs will not require much synchronization.

'Biggest challenge'
Nevertheless, "the biggest challenge for embedded software developers will be in figuring out how to partition their applications," Evensen said.

"It will be almost impossible for any new language to get a foothold," agreed Eric Heikkila, a project director at market watcher Venture Development Corp. (VDC), who moderated the panel.

"The inability of C/C++ code to parallelize coupled with its ubiquity throughout the embedded market is a major issue for multicore going forward," Heikkila wrote in a follow up email to EE Times. "Any alternative parallel programming languages certainly won't materialize in the embedded market, but instead will more likely gain momentum in a more mainstream computing market before making its way into embedded applications," he added.

On the other hand, embedded systems need better standards on several fronts to plow the way for multicore chips, Kleidermacher said.

"Communicating with accelerators is a nightmare because every vendor has their own API," he said, indicating the need for an overarching standards effort particularly between graphics processors and DSPs.

"That's not happening right now. Some chips may be too applications specific, but I think we could find more commonality here," he said.

In other areas, such as inter-processor communications, there also are too many proposed standards including MPI and the TIPC effort from the Multicore Association. He called on companies such as ARM to get more engaged with the Multicore Association.

"Right now there are no good standards and a lot of ad hoc solutions for communicating between cores and OS," said Evensen.

Kleidermacher also called on the Linux community to adopt Posix as a baseline for supporting standard communications.

"Linus Torvalds recently came out against Posix compliance for Linux, and that was a big mistake," he said. "It's one thing to say a standard needs to be modified, and Linus can do that, but you don't just give up on it," he said.

Failing grade
The software issues need to get sorted out soon. VDC estimates sales of multicore embedded processors will rise from $372 million in 2007 to 1.33 billion in 2009. So far, engineers are giving embedded software a low grade of just 2.06 out of five in terms of its readiness for multicore.

"When people first port their app to a multicore processor they are surprised they don't get a two or four-fold improvement, but something more like a 1.2x improvement," said Evensen.

Genard of Virtutech said many multicore environments exhibit non-deterministic behaviors and effects he called "Heisen-bugs" that make coding difficult.

"By the very fact you try to debug or instrument a device you may actually change its behaviors," he said.

- Rick Merritt
EE Times