I just read a EETimes report from a panel at the Power.org Developers Conference (actually, it is more accurately called the Power Architecture Developers Conference, of PADC), about programming multicore processors for the embedded market. Note that I was not there in person, so I can only take the few quotes in the article and comment on them. The main conclusions are that:
C/C++ is going to be the dominant language for embedded for the near future. Nothing really surprising at that.
C/C++ being dominant means that parallelism in multicore processors, especially shared-memory systems, will be harder to exploit. That is certainly true.
Tool vendors have no good idea about what to do next.
You cannot expect to get traction with a new language.
In a sense, blaming the market for not having the good sense to adapt new tools to tackle multicore.
I don’t think things have to be that bleak.
I do believe that there are some hopeful points that indicate that engineers and vendors are beginning to move towards ways to explore multicore:
1. Increased availability of shared-memory APIs like OpenMP and Pthreads is happening, even if that does not really help much considering that shared-memory programming itself is pretty broken.
2. I do not quite agree with the quote by Erik Heilikka that embedded is a trailing-end adopter of new programming languages:
“The inability of C/C++ code to parallelize coupled with its ubiquity throughout the embedded market is a major issue for multi-core 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.
Au contraire, the embedded market have many times adopted good solutions that are very different from mainstream software practice.
High-level model-driven tools like Matlab/Simulink and NI LabView are starting to generate parallel code from a higher-level abstraction. This is one very important way forward.
The use of UML and SDL and similar modeling/programming languages in the telecom sector should open for better code generators straight to parallel code.
Erlang is a good example of a good language for parallel systems that started in embedded and is now going mainstream.
So thanks to the domain-specific nature of most embedded work, tools can be created that support the creation of parallel implementations without forcing a programmer to care about shared memory and C. And the tools already exist.
Power.Org Dev Con: C Domination a Problem for Multicore
I just read a EETimes report from a panel at the Power.org Developers Conference (actually, it is more accurately called the Power Architecture Developers Conference, of PADC), about programming multicore processors for the embedded market. Note that I was not there in person, so I can only take the few quotes in the article and comment on them. The main conclusions are that:
In a sense, blaming the market for not having the good sense to adapt new tools to tackle multicore.
I don’t think things have to be that bleak.
I do believe that there are some hopeful points that indicate that engineers and vendors are beginning to move towards ways to explore multicore:
1. Increased availability of shared-memory APIs like OpenMP and Pthreads is happening, even if that does not really help much considering that shared-memory programming itself is pretty broken.
2. I do not quite agree with the quote by Erik Heilikka that embedded is a trailing-end adopter of new programming languages:
Au contraire, the embedded market have many times adopted good solutions that are very different from mainstream software practice.
So thanks to the domain-specific nature of most embedded work, tools can be created that support the creation of parallel implementations without forcing a programmer to care about shared memory and C. And the tools already exist.